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ABSTRACT 

The  formal  specification  language  Spec  is  used  for  writing  black-box  specifications 
for  large  software  systems.  These  black-box  specifications  describe  the  interface 
between  a  system  and  its  users,  as  well  as  internal  interfaces  between  modules.  Systems 
analysts  use  specifications  written  in  Spec  to  verify  the  customer's  requirements  during 
the  development  of  a  software  system. 

This  thesis  demonstrates  the  feasibility  of  designing  and  implementing  a  syntax 
directed  editor  for  a  subset  of  the  specification  language  Spec.  The  editor  is  a  software 
tool  for  writing  Spec  specifications  that  ensures  syntactic  correctness  of  such  specifi- 
cations. The  syntax  directed  editor  is  created  using  the  Synthesizer  Generator,  a 
Computer-Aided  Software  Engineering  (CASE)  tool  for  generating  language-based 
editors.  The  specification  for  the  editor  is  written  in  the  Synthesizer  Specification 
Language  (SSL)  which  is  based  on  an  attribute  grammar.  The  software  tool  developed  in 
this  thesis  supports  the  Requirements  Analysis  phase  of  the  software  development  cycle. 
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I.  INTRODUCTION 

A.  OVERVIEW 

Spec  is  a  fonnal  specification  language  designed  to  write  black-box  specifications  of 
software  systems.  These  black-box  specifications  describe  the  interface  between  a 
system  and  its  users  as  well  as  internal  interfaces  between  modules.  Specifications 
written  in  Spec  are  used  by  systems  analysts  to  verify  the  customer's  requirements.  The 
specification  is  then  translated  into  an  appropriate  programming  language  (such  as  Ada) 
by  programmers. 

CurrenUy,  Spec  is  a  research  tool  with  the  potential  to  become  an  industry  standard  in 
software  development.  An  eventual  goal  is  to  create  an  integrated  environment  of 
software  tools  for  Spec.  These  tools  would  include  an  editor,  type  checker,  consistency 
checker,  inheritance  expander,  pretty  printer,  test  oracle,  diagram  generator  and  a 
translator  to  Ada. 

A  syntax  directed  editor  is  the  primar>'  tool  of  such  an  integrated  environment.  The 
user  is  guaranteed  a  syntactically  correct  Spec  specification  at  the  end  of  each  editing 
session.  By  ensuring  syntactic  correcmess  as  the  specification  is  being  designed/edited, 
the  overall  time  spent  designing  the  system  is  reduced. 

This  thesis  discusses  the  development  of  SPECDEF,  a  syntax  directed  editor  for  a 
subset  of  the  Spec  specification  language.  Chapter  n  gives  a  general  description  of  a 
syntax  directed  editor  and  compares  two  primary  editor  generator  systems.  Chapter  III  is 


a  description  of  the  Spec  language.  The  complete  Spec  grammar  appears  in  Appendix  A. 
Chapter  IV  details  the  concepts  behind  the  Synthesizer  Generator,  design  decisions,  and  a 
practical  approach  to  designing  a  syntax  directed  editor  specification.  The  specification 
files  for  the  SPECDEF  editor  appear  in  Appendix  B.  A  user's  manual  for  the  SPECDEF 
editor  appears  in  Appendix  C,  and  a  listing  of  all  editor  system  commands  appears  in 
Appendix  D. 

B.  DESCRIPTION  OF  SOFTWARE  ENGINEERING  PRINCIPLES 

Computers  are  playing  an  increasingly  large  role  in  our  lives.  Many  manufacturing 
processes  are  being  automated,  retail  and  grocery  stores  have  computerized  pricing  and 
inventory  systems,  banks  are  providing  automatic  teller  machines,  travel  agents  make  our 
plane  reservations  through  computers,  etc.  In  order  for  these  and  other  computer  systems 
to  perform  useful  tasks,  reliable  and  efficient  software  is  required. 

Software  engineering  applies  scientific  and  mathematical  principles  to  the  develop- 
ment of  software  in  order  to  make  computers  useful  to  people.  Software  consists  of  the 
actual  programs,  all  documentation  and  user's  guides,  operating  procedures  and  test  cases 
that  are  associated  with  a  computer-based  system.  A  primary  goal  of  software  engi- 
neering is  the  development  of  effective  scientific  methods  for  producing  software  that 
meets  the  customer's  schedule  and  budget  constraints  while  satisfying  all  his  require- 
ments for  the  software  system.  [Ref.  1] 

Computers  can  perform  tasks  that  are  repetitious,  too  time  consuming,  or  too 
complicated  for  people  to  do  manually,  and  they  can  usually  jjerform  those  tasks  faster, 
with  greater  reliability,  more  efficiently  and  at  a  lower  cost  than  people  can.  In  order  for 


computers  to  be  useful,  the  software  system  designed  for  the  customer  must  be  able  to 
perform  all  functions  required  by  the  user  in  a  correct  and  efficient  manner.  Any  failure 
of  the  system  to  operate  correctly  could  be  costly  in  terms  of  lives,  equipment,  and 
money.  Software  systems  should  not  only  be  "correct",  i.e.,  conform  to  the  specification, 
but  also  should  perform  die  functions  desired  by  the  customer.  Correct  but  inappropriate 
systems  are  sometimes  built  because  the  software  developers  did  not  understand  the 
user's  needs,  or  the  software  cannot  adapt  to  changes  in  those  needs.  [Ref  1] 

Hardware  prices  have  decreased  by  about  50%  roughly  every  two  years.  This  in  turn 
has  triggered  a  demand  for  larger,  more  sophisticated  computer  applications.  It  is 
impossible  for  a  single  person  to  understand  or  to  build  large  and  complex  software 
systems.  Therefore,  a  software  development  organization  is  needed.  The  system  must  be 
organized  as  a  set  of  modules  that  are  small  enough  to  be  developed  by  a  single  person. 
Each  of  the  developers  in  the  organization  must  communicate  with  the  other  developers, 
either  directly  or  through  documentation.  This  documentation  must  be  precise  so  that  all 
developers  on  the  project  team  have  a  complete  and  correct  under- standing  of  the 
interface  between  the  module(s)  they  are  developing.  In  addition  to  this  formal 
documentation,  communication  is  extremely  important,  particularly  in  large  projects, 
where  project  members  come  and  go.  [Ref  1] 

The  software  development  process  consists  of  a  cycle  of  qualitative  activities: 
requirements  analysis,  functional  specification,  architectural  design,  implementation,  and 
evolution.  The  development  will  proceed  most  efficiently  if  these  activities  are  per- 
formed in  a  pipeline  fashion.   However,  each  activity  does  not  necessarily  end  when  the 


next  begins.  Often,  insights  are  gained  at  later  stages  that  trigger  modifications  or 
extensions  to  earlier  results.  Therefore,  feedback  is  essential.  The  relationship  between 
activities  of  the  sofrv^'are  development  cycle  is  illustrated  in  Figure  1 . 

Requirements  analysis  is  the  process  of  determining  and  documenting  the  customer's 
needs.  The  purpose  of  the  system,  as  well  as  any  constraints  on  its  development,  is 
determined  at  this  stage.  A  systems  interface  is  proposed  and  formalized  in  the 
functional  specification  stage.  This  interface  only  describes  those  aspects  of  the  system 
behavior  that  are  visible  to  the  user  or  to  other  external  systems.  The  system  is  then 
decomposed  into  modules  in  the  architectural  design  phase.  Internal  interfaces,  i.e.,  those 
not  visible  to  the  user,  are  defined  here.  Implementation  is  the  production  of  a  program 
for  each  of  the  modules.  The  data  structures  and  algorithms  used  within  each  module  are 
defined  here.  Finally,  the  evolution,  or  repair  process,  allows  for  adaptation  of  the 
system  to  changing  needs  of  the  customer.  Any  discrepancies  between  the  specification 
and  the  implementation  that  are  discovered  after  system  delivery  are  repaired  here,  and 
the  capabilities  of  the  system  are  expanded  as  new  requirements  are  discovered.  This 
evolution  requires  repeating  the  previous  four  steps  of  the  software  development  cycle. 
[Ref  1] 

The  SPECDEF  editor  will  be  useful  mostly  in  the  requirements  analysis  phase  of  the 
software  development  cycle,  and  to  a  lesser  extent  in  the  functional  specification  and 
architectural  design  phases. 
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Figure  1 
Software  Development  Cycle 


Thorough  analysis  and  testing  of  each  module  is  absolutely  necessary  if  a  "correct" 
system  is  to  be  developed.  A  project  database  should  be  utilized  to  record  and  distribute 
all  information  about  the  state  of  the  development  process.  This  database  will  contain  a 
variety  of  documents,  including  the  requirements,  designs,  justifications  for  those 
designs,  the  code,  test  cases  and  results,  user's  manuals,  the  schedule  of  the  development 
project,  work  assignments,  etc.  The  larger  the  system,  the  larger  the  database,  and  the 
greater  the  need  for  a  database  management  system.  For  engineering  applications,  a 
specialized  engineering  database  system  is  required  to  efficientiy  manage  the  project 
database.  This  is  a  relatively  new  development,  and  mature  systems  are  not  yet  widely 
available.  Future  versions  of  SPECDEF  should  interface  to  this  design  database.  [Ref  1] 


C.  COMPUTER-AIDED  SOFTWARE  ENGINEERING  (CASE) 

The  time  spent  in  the  requirements  analysis,  functional  specification  and  architectural 
design  stages  of  the  software  development  cycle  has  been  greatly  reduced  by  the 
advancements  made  in  computer-aided  software  engineering  (CASE)  tools.  These  tools 
assist  the  systems  analyst  and  software  engineer  in  specifying  the  system's  requirements 
and  design.  Many  of  the  design  and  development  problems  inherent  in  medium  to  large 
software  projects  are  reduced  or  eliminated  by  the  use  of  CASE  tools.  [Ref.  2] 

Some  CASE  tools  can  automatically  generate  code  from  the  software  design 
specification.  Two  benefits  are  achieved  from  this.  First,  the  implementation  time  is 
substantially  reduced  since  the  code  (or  at  least  part  of  it)  is  being  generated  automa- 
tically. Secondly,  the  software  engineer  may  feel  more  confident  about  the  quality  of  the 
generated  code  because  it  was  produced  by  a  software  tool  that  has  itself  been  thoroughly 
tested  and  debugged.  [Ref  2] 

Truly  generalized  code  generation  is  not  available  in  any  of  today's  general-purpose 
tools.  However,  specialty  development  tools  that  focus  on  a  particular  type  of  software, 
such  as  user  interface  design  tools,  are  available  that  will  generate  code.  This  thesis  will 
discuss  the  use  of  one  such  tool,  the  Synthesizer  Generator,  which  generates  a  syntax 
directed  editor  program.  This  generated  program  is  in  fact  another  example  of  a  CASE 
tool. 

In  general,  CASE  tools  are  designed  to  increase  the  productivity  of  systems  analysts 
and  software  engineers.  Many  of  these  tools  are  actually  requirements  and  design 
specification  editors  that  provide  output  in  specific  formats,  often  graphically  oriented. 


that  can  be  read  and  understood  by  end-users  and  developers  alike.  They  eliminate  the 
drudgery  of  drawing  and  redrawing  data  flow  diagrams,  module  hierarchy  charts,  etc., 
that  often  change  as  the  project  development  proceeds.  Time  is  saved  and  formats  are 
consistent.  Future  versions  of  the  SPECDEF  editor  should  interface  with  tools  for 
generating  such  diagrams  and  other  summary  information.  [Ref.  2] 

D.  FOURTH-GENERATION  LANGUAGES 

The  term  "fourth-generation  language"  can  be  looked  at  in  two  different  ways.  Some 
authors  use  the  term  to  refer  to  application  generator  programs.  Applications  generators 
are  software  tools  that  take  a  design  specification  as  input  and  produce  compilable  code 
as  output.  When  used  in  this  context,  the  "fourth-generation  language"  in  not  always  a 
programming  language  in  the  sense  that  a  programming  language  is  intended  to  describe 
a  program  [Ref.  3].  This  context  includes  many  CASE  tools,  such  as  program  generators. 
Fourth-generation  languages  in  this  context  are  sometimes  thought  of  as  higher-level 
focused  languages  that  provide  mechanisms  for  accessing  data  bases  [Ref.  2].  Many 
software  professionals  think  of  fourth-generation  languages  as  a  form  of  CASE  [Ref.  2]. 

Other  authors,  when  referring  to  "fourth-generation  languages,"  mean  a  particular 
class  of  modem  programming  languages,  including  Ada.  Fourth-generation 
programming  languages  provide  mechanisms  for  data  abstraction.  An  encapsulation 
facility  supports  the  separation  of  the  specification  and  defmition  of  data  structures, 
information  hiding,  and  name  access  by  mutual  consent.  A  facility  for  passing  messages 
between  concurrent  tasks  to  maintain  synchronization  and  communication  supports 
concurrent  programming.  [Ref.  3] 


A  software  crisis  developed  in  the  mid  1970's  because  software  development  had 
become  labor  intensive  rather  than  a  labor-saving  activity.  There  were  problems  with 
responsiveness  of  computer  systems  to  customers'  needs,  reliability  of  software,  escal- 
ating software  development  costs,  maintainability  of  software  systems,  timeliness  of 
development  of  software  systems,  transportability  of  software  from  one  operating  envi- 
ronment to  another,  and  efficiency  of  the  software  in  terms  of  processing  time  and 
memory  space.  Software  systems  were  becoming  increasingly  larger  and  more  complex. 
The  most  popular  programming  languages  at  that  time,  FORTRAN  and  COBOL,  did  not 
reflect  newly  developed  software  engineering  principles  and  were  not  suitable  for 
embedded  computer  systems.  An  embedded  computer  is  one  that  is  a  component  of  a 
larger  system,  e.g.,  a  guidance  computer  on  a  missile,  or  a  target  tracking  computer  in  a 
weapon  system,  etc.  [Ref.  4] 

The  United  States  Department  of  Defense  (DoD)  recognized  this  software  crisis. 
There  was  no  standardization  in  DoD  projects  as  far  as  programming  languages  were 
concerned.  In  response  to  these  problems,  DoD  commissioned  a  worldwide  language 
design  competition  with  the  goal  of  developing  a  single  high-order  language  suitable  for 
use  in  embedded  computer  systems  as  well  as  conforming  to  other  well-defmed  require- 
ments. The  result  of  that  competition  was  Ada.  It  is  designed  specifically  for  large, 
software-intensive,  real-time  embedded  computer  systems.  However,  it  is  suitable  for 
other  application  areas  as  well.  Ada  both  embodies  and  enforces  modem  software 
engineering  development  principles,  such  as  structured  constructs,  information  hiding. 


and  abstraction.  Ada  is  now  a  prime  language  in  the  computing  industry,  as  well  as  being 
the  required  language  for  embedded  computer  systems  in  DoD  projects.  [Ref.  4] 

Both  viewpoints  on  the  definition  of  a  fourth-generation  language  are  applicable  to 
this  thesis.  In  the  first  sense,  that  of  an  application  generator,  the  Synthesizer  Generator 
is  a  CASE  tool  that  takes  as  input  an  editor  specification  written  in  a  fourth-generation 
language  and  outputs  compilable  C  code,  which  is  then  compiled  into  an  executable 
editor  program.  In  the  second  sense,  that  of  a  class  of  programming  languages,  the 
purpose  of  the  editor  produced  by  the  Synthesizer  Generator  is  to  support  the  early  stages 
of  software  design  for  eventual  translation  in  to  a  fourth-generation  language,  specifically 
Ada. 


n.  BACKGROUND 

A.  GENERAL  DESCRIPTION  OF  A  SYNTAX  DIRECTED  EDFTOR 

A  syntax  directed  editor  is  a  software  tool  for  creating  or  modifying  programs  in  such 
a  way  that  correct  syntax  is  always  maintained.  It  will  not  allow  syntactically  incorrect 
constructs  to  be  entered.  Generally,  the  editor  is  designed  for  one  specific  programming 
language,  although  editors  exist  that  allow  different  languages  to  be  programmed  into  it. 
Often,  the  editor  is  the  prime  component  of  a  set  of  programming  tools  that  make  up  an 
integrated  programming  environment. 

Most  syntax  directed  editors  are  screen-based,  i.e.,  program  text  is  entered  at  the 
location  indicated  by  the  display  cursor,  and  the  screen  display  is  automatically  updated, 
just  as  most  text  editors  do.  But  text  editors,  as  the  name  implies,  only  allow  modifi- 
cation of  the  text,  whereas  syntax  directed  editors  allow  modification  of  the  syntactic 
structure  of  the  program,  as  well  as  the  text  itself.  As  the  text  is  entered,  it  is  checked  for 
syntactic  correctness,  and  errors  are  immediately  detected  and  appropriate  messages 
displayed  to  the  user.  This  prevents  the  user  from  writing  programs  that  are  syntactically 
incorrect.  [Ref.  5,6] 

In  most  syntax  directed  editors,  text  is  entered  by  creating  a  template,  or  a  skeleton, 
of  some  syntactic  construct,  and  filling  in  the  detail  later.  These  templates  form  a  parse 
tree  and  only  allow  s>Titactically  correct  constructs  to  be  generated.  The  user  selects  a 
node  of  the  parse  tree  that  contains  a  non-terminal  to  fill  in  the  detail.  This  non-terminal 
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can  be  expanded  into  valid  syntactic  alternatives.  Some  editors  will  display  a  list  a  valid 
choices  for  the  current  node.  The  user  can  also  enter  directly  the  desired  text,  and  if  the 
entry  is  not  syntactically  correct,  the  editor  will  then  display  a  list  of  alternatives  to  the 
user.  This  process,  known  as  programming  by  selection,  is  partic-ularly  beneficial  in  a 
learning  envirDnment  because  the  time  to  learn  the  rules  of  the  language  (the  syntax)  is 
reduced.  Figure  2  is  an  example  of  the  programming  by  selec-tion  process  for  a 
compound  statement  using  an  arbitrary  language.  [Ref.  5,6] 


Program  Statement 
begin  <stmntlst>  end 
begin  <stmntlst>;  <stmnt>  end 
begin  <stmnt>;<stmnt>  end 
begin  <assign_stmnt>;  <stmnt>  end 
begin  x  :-  5;  <stmnt>  end 
begin  x  :=  5;  <proc_call>  end 
begins:  .=  5;p(x)er\d 


Transformation  Selected 

<stmntlst> ><stmntlst>;  <stmnt> 

<stmntlst> >  <stmnt> 

<stmnt> >  <assign_stmnt> 

<assign_stmnt> >  x  :=  5 

<stmnt> >  <proc_call> 

<proc_call> ^  p(x) 


Figure  2 
Programming  by  Selection 


Since  visual  display  units  (VDUs)  generally  can  only  display  24  lines  of  text  at  a 
time,  it  is  impossible  to  display  much  of  the  parse  tree  graphically  on  the  screen.  How- 
ever, an  overall  view  of  the  program  (or  at  least  a  larger  portion  of  it)  is  possible  by 
unparsing  the  tree,  i.e.,  displaying  text  down  to  a  certain  level  of  detail  and  omitting  the 
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remaining  detail.  The  omitted  portions  are  commonly  replaced  by  ellipses  ("...")  so  the 
overall  view  of  the  structure  remains  intact.  The  user  may  then  select  a  particular  portion 
on  which  to  zoom  in  and  display  greater  detail.  [Ref.  5] 

Changes  are  made  to  the  structure  of  the  program  using  the  central  commands  of  the 
editor.  The  editor  might  allow  changes  in  terms  of  operations  on  the  branches  of  the 
parse  tree,  by  matching  subtrees  and  substitution,  or  by  entering  arbitrary  text  and  repar- 
sing  the  tree.  For  example,  suppose  the  user  wanted  to  rename  a  variable  "red"  to  "blue". 
Variables  are  a  construct  of  the  language,  i.e.,  a  subtree.  Changing  the  symbol  of  this 
subtree  from  "red"  to  "blue"  does  not  affect  other  text  strings  in  the  parse  tree  that  contain 
the  substring  "red",  i.e.,  a  variable  "fred"  is  not  changed  to  the  variable  "fblue".  This 
kind  of  structural  editing  (as  opposed  to  simple  text  editing)  avoids  unintended  changes 
to  the  program.  If  this  were  not  the  case,  i.e.,  if  such  a  substitution  replaced  every 
instance  of  the  substring  "red"  throughout  the  program,  the  result  would  be  potentially 
disastrous.  [Ref.  5] 

Structural  commands  insert,  copy,  move  and  delete  subtrees  within  the  parse  tree. 
Subtrees  can  also  be  clipped,  or  contracted  into  a  non-terminal  symbol  of  the  grammar. 
These  clipped  pieces  are  saved,  and  can  be  reused  at  other  locations  using  a  special  form 
of  the  insert  command.  The  benefit  of  this  facility  is  the  time  saved  by  copying  or 
moving  whole  subtrees  from  one  location  in  the  parse  tree  to  another  rather  than  having 
to  re-construct  the  subtree  at  the  new  location.  [Ref.  5] 
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Most  syntax  directed  editors  incorporate  a  pretty-printing  function.  This  can  be 
reflected  on  the  display  screen  as  well  as  on  the  hardcopy  output  Pretty-printing  might 
be  a  selectable  function,  or  it  might  be  done  automatically.  [Ref.  5] 

A  syntax  directed  editor  can  also  maintain  some  semantic  constraints.  For  example, 
every  variable  that  is  used  must  be  declared.  Such  facilities  are  useful  for  preventing 
some  classes  of  errors. 

The  SPECDEF  editor  incorporates  some  of  the  facilities  mentioned  above.  It  is  a 
screen-oriented  hybrid  editor  that  modifies  the  structure  of  the  edited  object  by  template 
insertion  as  well  as  direct  text  entry.  The  valid  choices  for  template  insertion  are 
displayed  to  the  user  at  each  node  of  the  parse  tree  when  that  node  is  selected.  Textual 
changes  to  one  construct  do  not  affect  the  same  text  in  other  constructs.  Subtrees  can  be 
clipped  and  copied  or  moved  to  other  locations  in  the  parse  tree.  Pretty-printing  is 
automatic  in  the  sense  that  indentation  and  line  breaks  are  designed  into  the  unparsing 
schemes. 

SPECDEF  does  not,  however,  have  any  provisions  for  semantic  checking  of  variable 
declarations  or  for  elision  of  detail  into  ellipses.  Future  versions  of  SPECDEF  will  be 
integrated  with  a  type  checker  and  a  consistency  checker  that  will  help  maintain  semantic 
constraints.  Provisions  for  elision  of  detail  may  also  be  incoiporated  in  future  versions  of 
tiie  SPECDEF  editor. 

B.  SYNTAX  DIRECTED  EDFTOR  GENERATORS 

An  important  area  of  research  in  computer  science  is  that  of  language-based 
programming  environments.  Probably  the  most  significant  programming  tool  in  such  an 
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environment  is  a  syntax  directed  editor.  Integrating  a  syntax  directed  editor  with 
execution  and  debugging  facilities  creates  a  powerful  programming  tool.  Several  such 
systems  have  been  developed,  e.g.,  GANDALF  [Ref.  7,8],  and  the  Cornell  Program 
Synthesizer  [Ref.  9].  The  Synthesizer  Generator  [Ref.  10,11]  is  an  outgrowth  of  the 
Cornell  Program  Synthesizer. 

Both  GANDALF  and  the  Synthesizer  Generator  have  the  capability  to  create  editors 
for  languages  other  than  programming  languages,  such  as  verification  languages  or 
specification  languages.  The  Synthesizer  Generator  was  selected  as  the  primary  tool  for 
this  thesis  because  of  the  availability  of  mutual  support  with  a  parallel  research  project  in 
prototyping  languages  currently  under  development  at  the  Naval  Postgraduate  School. 
Also,  at  this  stage  of  research,  there  was  not  a  need  to  generate  a  multiple  user  environ- 
ment such  as  GANT)ALF  generates.  The  discussion  on  GANDALF  is  offered  for 
purposes  of  comparison.  Follow-on  research  to  this  thesis  may  wish  to  investigate  the 
use  of  GANDALF  to  create  a  multiple  user  environment. 

1.  The  GANDALF  System 

The  GANDALF  System  is  a  software  tool  that  generates  integrated  environments 
that  are  language-specific.  Two  different  kinds  of  environments  are  possible  using  this 
sysitm--programming  environments  and  software  development  environments.  A 
programming  environment  is  a  highly  interactive  knowledge-based  environment  for  a 
single  programmer  working  on  a  small  project.  A  software  development  environment, 
which  is  the  primary  purpose  of  the  GANDALF  project,  is  one  in  which  multiple 
programmers  work  on  large  projects.  [Ref  8] 
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The  heart  of  the  GANDALF  project  is  designed  around  the  ALOE  editor 
generator  system,  which  stands  for  A  Language  Oriented  Exiitor.  A  language  oriented 
editor  is  also  known  as  a  syntax  directed  editor  or  a  structure  editor  in  the  literature. 
ALOE  is  actually  the  common  kernel  that  is  used  by  all  syntax  directed  editors  generated 
with  this  system.  A  specific  instantiation  of  a  syntax  directed  editor  is  known  as  an 
ALOE  editor.  ALOEGEN  is  an  ALOE  editor  that  is  used  to  create  the  syntactic 
descriptions  of  a  language  that  can  then  be  used  in  conjunction  with  ALOELIB,  which  is 
library  support  to  add  semantic  actions  and  additional  commands,  to  create  a  syntax 
directed  editor  for  the  specific  language.  [Ref  7] 

The  user  interface  of  all  generated  ALOE  editors  are  tree-oriented  full-screen 
interfaces.  There  is  a  set  of  language-independent  commands,  such  as  subtree  deletion 
and  cursor  motion,  as  well  as  a  set  of  language-specific  operations  that  represent 
structures  of  the  language,  such  as  Pascal  while  statements  or  Ada  packages.  [Ref  7] 

As  a  programmer  creates  or  edits  a  program  with  an  ALOE,  the  program  is 
displayed  much  the  same  way  as  a  text  editor  would  display  it.  But  the  representation  is 
based  on  the  structure  of  the  program  rather  than  simply  as  a  string  of  characters.  This 
structure  is  an  abstract  syntax  tree.  The  programmer  moves  about  the  program  by  way  of 
this  tree  structure.  The  cursor  will  highlight  an  entire  structural  unit,  such  as  a  Pascal  if- 
then-else  construct,  or  a  specific  non-terminal  within  the  structural  unit,  rather  than  just  a 
single  character.  Operations  are  performed  on  the  structure  of  the  program,  i.e.,  insertion 
or  deletion  of  structural  units,  or  expansion  of  non-terminals.  [Ref.  8] 
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As  stated  earlier,  the  primary  focus  of  the  GANDALF  project  is  the  generation  of 
software  development  environments  that  would  support  multiple  programmers  working 
on  a  large  project.  This  type  of  environment  also  has  an  ALOE  editor  as  its  basis,  but  in 
addition  provides  a  system  version  control  editor  and  a  project  management  editor  to 
solve  programming-in-the-large  and  programming-in-the-many  problems  respectively. 
These  problems  are  significandy  harder  to  solve  because  of  the  interaction  required 
between  various  modules  developed  by  different  programmers  on  the  team.  Research  is 

continuing  in  this  area.  [Ref.  8] 
2.  The  Synthesizer  Generator 

The  Synthesizer  Generator  is  a  system  that  creates  a  language-specific  editor  from 
a  specification  of  the  language's  abstract  syntax,  context-sensitive  relationships,  display 
format,  concrete  input  syntax,  and  transformation  rules  for  restructuring  objects.  The 
specification  language  for  the  Synthesizer  Generator,  SSL  (for  Synthesizer  Specification 
Language),  is  based  on  the  concept  of  an  attribute  grammar.  An  attribute  grammar  is  an 
extension  of  a  context-free  grammar.  The  extensions  are  the  attributes  which  have  been 
attached  to  the  nonterminal  symbols.  The  value  of  these  attributes  is  defined  by  attribute 
equations.  This  mechanism  can  specify  how  widely  separated  parts  of  a  derivation  tree 
can  be  constrained  by  the  context  of  the  rest  of  the  tree.  [Ref.  10] 

Specifications  written  in  SSL  are  different  from  specifications  written  for  other 
systems  that  are  based  on  attribute  grammars.  This  is  because  SSL  has  several 
innovations,  e.g.,  the  capability  to  merge  abstract-syntax  definitions  and  user-defined 
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attributes,  a  notation  that  allows  specifications  to  be  broken  into  separate  modules,  and 
the  manner  in  which  the  parser  is  incorporated  into  the  system.  [Ref.  10] 

There  are  two  basic  components  that  comprise  the  Synthesizer  Generator:  (1)  a 
translator  that  converts  SSL  specifications  into  various  tables  as  output,  and  (2)  an  editor 
kernel  with  an  attributed-tree  data  type  and  a  driver  for  manipulating  attributed  trees 
interactively.  The  kernel  executes  operations  on  the  current  tree  according  to  keyboard 
and/or  mouse  commands.  A  shell  program  named  sgen  invokes  the  translator  and  pro- 
duces the  syntax  directed  editor  for  the  specified  language  ftx)m  the  tables  that  are  output 
from  the  translator.  [Ref  11] 

Objects  being  edited  with  an  editor  produced  by  the  Synthesizer  Generator  are 
represented  as  attributed  derivation  trees.  Each  modification  to  the  object  being  edited 
causes  the  attribute  values  throughout  the  tree  to  be  updated.  If  a  modification  results  in 
the  violation  of  any  context-dependent  constraints,  the  display  is  annotated  with  error 
messages  to  provide  the  user  with  immediate  feedback.  [Ref.  1 1] 

The  editor  produced  by  the  Synthesizer  Generator  displays  constructs  of  the 
language  as  templates,  or  predefined,  formatted  patterns.  Non-terminals  within 
constructs  can  be  thought  of  as  placeholders  where  additional  insertions  can  be  made 
through  a  transformation  equation.  When  the  user  selects  a  subterm  (i.e.,  a  placeholder) 
a  menu  of  possible  transformations  is  listed.  A  transformation  is  invoked  either  by 
typing  the  name  or  making  a  menu  selection  with  a  mouse.  Transformation  definitions 
are  type-checked  when  the  SSL  specification  is  compiled  into  an  editor,  so  it  is 
impossible  for  a  transformation  to  introduce  context-free  syntax  errors.  [Ref  1 1] 
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In  addition  to  the  transformations,  which  are  language  specific,  every  editor 
generated  by  the  Synthesizer  Generator  contains  language  independent  system  commands 
such  as  cut-to-clipped  and  paste-from-clipped.  The  cut  operation  differs  from  ordinary 
text  editors,  which  would  delete  the  selected  text  and  leave  the  cursor  at  that  position.  In 
the  syntax  directed  editor,  the  cut  operation  replaces  the  selected  subterm  with  a  place- 
holder, thus  maintaining  the  correcmess  of  the  context-free  syntax.  The  paste  operation, 
conversely,  replaces  the  placeholder  term  with  the  previously  cut  subterm.[Ref.  1 1] 

The  Synthesizer  Generator  is  written  in  C  and  runs  under  the  Berkeley  UNIX 
system.  Editors  can  be  generated  for  specific  windowing  systems,  such  as  VIDEO,  SUN, 
and  X-Windows.  There  are  a  number  of  selectable  options  when  invoking  sgen  that 
affect  the  method  of  generation  and  the  capabilities  of  the  generated  editor.  For  a 
complete  list  of  these  options,  refer  to  Appendix  B  of  [Ref.  11]. 
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m.  AN  OVERVIEW  OF  THE  SPEC  SPECIFICATION  LANGUAGE 

A.  THE  PURPOSE  OF  SPEC 

The  functional  specification  stage  of  the  software  development  cycle  gives  a  black- 
box  specification  of  the  software  project,  i.e.,  only  the  interface  between  modules  is 
described,  not  the  inner  workings.  Spec  is  a  formal  language  for  writing  such  black-box 
specifications,  as  well  as  for  specifying  the  internal  interfaces  of  the  proposed  system 
during  the  architectural  design  phase.  [Ref.  12] 

A  precise,  formal  specification  of  a  proposed  software  system  is  essential  in  order  to 
ensure  that  everyone  on  the  development  team  understands  and  agrees  with  the  interpre- 
tation of  the  user's  requirements.  Programming  languages,  such  as  Ada,  are  formal,  but 
because  they  are  designed  for  describing  algorithms  and  data  structures  rather  than  the 
actual  behavior  of  a  module,  they  are  not  suited  for  writing  black-box  specifications. 
Spec  is  designed  specifically  for  defining  the  behavior  of  software  modules.  The  formal 
notation  of  Spec  provides  the  precision  needed  to  prevent  the  ambiguity  inherent  in 
English  and  other  informal  notations.  [Ref  12] 

Spec  uses  the  event  model  to  define  the  behavior  of  a  proposed  system.  The  event 
model  describes  computations  in  terms  of  modules,  events  and  messages. 

A  module  is  a  black  box  that  interacts  with  other  modules  only  by  sending  and 
receiving  messages.  An  event  occurs  when  a  message  is  received  by  a  module  at  a 
particular  instant  of  time.  A  message  is  a  data  packet  that  is  sent  from  one  module 
to  another.  (Berzins,  1987,  p.  2) 
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Modules  can  model  either  software  components,  or  external  systems  such  as  peripheral 
hardware  or  even  the  user.  Messages  are  accepted  by  a  module  one  at  a  time.  The  length 
of  a  message  is  arbitrary.  It  is  assumed  that  every  message  sent  eventually  arrives  at  its 
destination.  [  Ref.  1] 

The  sequence  of  messages  that  are  received  by  a  module  determine  what  kind  of 
response  will  occur.  Modules  are  classed  as  mutable  or  immutable  depending  on  how 
the  module  reacts  to  messages.  If  the  response  of  the  module  can  depend  on  one  or  more 
messages  received  prior  to  the  most  recently  received  message,  the  module  is  mutable. 
Mutable  modules  behave  as  if  they  had  internal  states  or  memory.  If  the  module's 
response  to  every  possible  message  depends  solely  on  the  most  recentiy  received 
message,  the  module  is  immutable.  A  module  is  immutable  if  and  only  if  it  is  not 
mutable.  Immutable  modules  behave  more  like  mathematical  functions.  [Ref.  12] 

B.  MODULE  DESCRIPTIONS 

Five  types  of  modules  can  be   specified  in   Spec:      defmitions,  functions,  state 

machines,  abstract  data  t>T)es,  and  instances  of  generic  modules. 
1.  Definition  Modules 

Definition  modules  contain  descriptions  of  concepts  that  are  not  unique  to  any 
particular  function,  machine,  or  type  declaration,  but  are  instead  available  to  be  shared 
among  many  modules  through  importation.  Only  concepts  may  be  declared  in  definition 
modules.  Defmition  modules  may  also  import  other  modules.  [Ref.  1] 

Concepts  describe  the  logical  assertions  that  define  the  behavior  of  modules. 
They  can  define  constant  symbols,  symbolic  type  names,  predicates  (relationships)  and 
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functions  (attributes).  These  conceptual  representations  are  introduced  by  the  keyword 
CONCEPT.  Concepts  can  be  explicitly  exported  to  other  modules  through  an  EXPORT 
clause,  as  well  as  imported  from  other  modules  through  an  IMPORT  clause  (provided  it 
has  been  explicidy  exported  from  the  module  in  which  it  is  defined).  [Ref.  1] 

Definition  modules  form  the  primary  subset  of  the  requirements  analysis  phase  of 
the  software  development  cycle.  In  requirements  analysis,  a  model  of  the  problem 
domain  is  created  to  record  facts  about  the  problem  and  the  environment  of  the  proposed 
system  needed  by  the  developers  in  later  stages.  These  facts  are  represented  as  concepts 
contained  in  definition  modules.  The  SPECDEF  tool  developed  in  this  thesis  treats  the 
subset  of  the  Spec  language  used  in  this  process. 
2.  Function  Modules 

Function  modules  are  one  of  the  three  primary  module  types  in  Spec  (the  others 
being  machine  modules  and  type  modules).  A  function  module  behaves  like  a 
mathematical  function  in  that  it  calculate  the  value  on  a  data  type.  [Ref.  1 2] 

A  function  usually  will  perform  only  one  task  or  service,  so  they  will  only  accept 
anonymous  (i.e.,  unnamed)  messages.  Messages  in  a  function  module  define  the 
"operations"  that  the  function  may  perform.  They  are  introduced  by  the  keyword 
MESSAGE.  [Ref.  1,12,13] 

Each  message,  or  operation,  returns  a  value  in  the  form  of  a  REPLY  message.  A 
variety  of  responses  can  be  defined  with  WHEN  clauses,  which  specify  preconditions 
similar  to  the  Pascal  case  statement  or  the  switch  statement  in  C.  If  none  of  the  WHEN 
clauses  apply,  an  OTHERWISE  clause  handles  the  remaining  cases.     If  a  message 
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response  is  to  report  an  abnormal  condition,  a  REPLY  EXCEPTION  message  is  returned. 
Postconditions  that  must  be  satisfied  by  the  outgoing  message  are  specified  with  a 
WHERE  clause.  [Ref.  1,12,13] 

To  illustrate  the  above  concepts,  Figure  3  depicts  a  function  /  that  accepts  an 
anonymous  message  consisting  of  an  input  variable  of  type  typel.  If  the  input  variable 
satisfies  precondition  easel,  the  returned  value  is  the  output  variable  of  typel,  with  a 
postcondition  that  must  also  be  satisfied.  If  the  input  variable  satisfies  precondition 
easel,  an  abnormal  situation  exists,  so  the  returned  value  is  the  exception /az7ure7.  If 
neither  of  the  preconditions  can  be  met,  then  the  OTHERWISE  clause  takes  effect  and  an 
exception /<3i7wr^2  is  returned. 


FUNCTION/ 

MESSAGE  (input-var :  typel) 
WHEN  easel  (input-var) 

REPLY  (output-var :  typel) 

VJHERE  postcondition  (output-var,  input-var) 
WHEN  case2  (input-var) 

REPLY  EXCEPTION /az7ure7 
OTHERWISE  REPLY  EXCEPTION /a//ure2 

END 


Figure  3 
Example  of  a  Function  Module 


3.  Machine  Modules 

Machines  are  mutable  modules  that  have  an  intemal  state.  The  conceptual  model 
of  that  state  describes  the  behavior  of  the  module,  rather  than  the  messages  received  in 
the  past.  The  keyword  STATE  introduces  the  declaration  of  the  components  of  the 
conceptual  model  of  the  state,  and  any  restrictions  on  the  set  of  meaningful  states  are 
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given  in  an  ESTVARIANT  clause.  Restrictions  on  the  initial  state  are  given  in  an 
INITIALLY  clause.  Input  stimuli  to  the  machine  which  invoke  actions  are  defined  in 
MESSAGE  clauses.  The  actions  can  be  any  combination  of  a  REPLY,  a  REPLY 
EXCEPTION,  one  or  more  SEND  statements,  or  a  TRANSITION  to  a  new  state. 
Transitions  are  given  as  equations  that  describe  the  change  cither  forwards  or  backwards 
in  time,  whichever  is  simpler  (i.e.,  in  terms  of  the  state  before  the  transition  or  in  terms  of 
the  state  after  the  transition).  Messages  can  be  sent  to  modules  other  that  the  origin  of  the 
incoming  message.  This  is  done  using  a  SEND  statement  instead  of  a  REPLY.  There 
can  be  any  number  of  SEND  statements,  but  only  one  REPLY  statement.  [Ref.  1,12,13] 

The  example  in  Figure  4  depicts  a  machine  called  buffer  which  has  a  state  model 
consisting  of  a  single-valued  state-var  of  type  typel.  The  statements  INVARIANT  true 
and  INITIALLY  true  indicate  there  are  no  restrictions  on  the  states  of  the  machine.  If  the 
stimulus  read  is  sent  to  the  machine,  the  reply  is  the  current  value  of  state-var.  If  the 
stimulus  update  is  sent  with  the  parameter  new-value  of  the  type  typel,  the  state  of  the 
machine  is  changed  by  assigning  the  new-value  to  state-var.  When  the  transition  is 
complete,  the  reply  message  done  is  sent  to  the  initiator  of  the  stimulus. 
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MACHINE  bi^er 

STATE  (state-var :  typel) 
INVARIANT  true 
JNTTIALLY  true 

MESSAGE  read 

REPLY  (result :  typel) 
WHERE  result  =  staie-var 

MESSAGE  update  {new-value  :  typel) 

TRANSITION  siate-var  =  new-value 
REPLY  done 

END 


Figure  4 
Example  of  a  Machine  Module 

4.  Type  Modules 

Abstract  data  t>'pes  are  defined  in  type  modules.  An  abstract  data  type  consists  of 
a  set  of  values  and  a  set  of  primitive  operations  that  operate  on  those  values.  In  the  type 
module,  each  operation  is  represented  by  a  named  message.  The  data  type  is  described  in 
terms  of  a  conceptual  model  rather  than  the  actual  data  structure  used  in  the  implemen- 
tation. The  implementation  of  the  data  type  can  change  to  improve  performance,  but  the 
conceptual  model  will  still  be  valid.  The  keyword  MODEL  introduces  the  tuple  that 
represents  each  instance  of  the  data  type.  The  components  of  the  tuple  can  have 
restrictions  specified  in  an  INVARIANT  clause.  The  effects  of  the  operations  can  be 
described  by  CONCEPT  clauses.  Type  modules  can  be  either  mutable  or  immutable. 
[Ref.  12] 
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5.  Instance  Modules 

An  instance  module  is  used  to  make  an  instance  or  partial  instantiation  of  a 
generic  module.  This  is  useful  for  renaming  concepts  in  other  modules  before  importing 
or  inheriting  them.  For  example,  if  module  m  contains  a  concept  c  that  you  wish  to 
import,  but  you  have  already  defined  a  local  concept  using  the  same  name  and  argument 
types  but  with  a  different  meaning,  one  of  the  two  concepts  will  have  to  be  renamed.  If 
the  name  you  have  chosen  for  your  local  concept  is  a  good  one,  then  it  is  better  to  rename 
the  imported  concept.  To  do  this,  you  must  first  create  a  new  instance  of  module  m,  say 
new-m,  in  which  you  declare  a  renaming  of  concept  c  to  new-c.  The  renamed  concept 
can  now  be  imported  from  the  new  instance  of  module  m  (i.e.,  module  new-m).  This 
example  is  illustrated  in  Figure  5. 


INSTANCE  new-m  =  m 

RENAME  c  AS  new-c 

END 

"  The  renamed  concept  can  now 

be 

imported  as 

follows: 

IMPORT  new-c  FROM  new-m 

Figure  5 
Using  an  Instance  Module  to  rename  a  concept 


C.  OTHER  FEATURES 

1.  Concepts  used  as  Subprograms 

Concepts,  which  were  briefly  described  above,  are  of  great  benefit  in  simplifying 
descriptions  of  complex  softNvare  systems.     Long  expressions  in  predicate  logic,  for 
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example,  can  be  decomposed  into  several  concepts  that  are  easily  understood  individ- 
ually, making  the  overall  expression  more  understandable.     Concepts  in  Spec  arc 
analogous  to  subprograms  in  a  programming  language. 
2.  Inheritance  in  Spec 

Spec  has  an  inheritance  mechanism  that  allows  constraints  that  are  common  to  the 
interface  of  several  modules  to  be  specified.  This  is  particularly  useful  in  specifying 
large  software  systems  because  it  helps  achieve  a  consistency  in  the  interface  of  several 
modules.  [Ref.  12] 

Inheritance  applies  to  entire  modules.  An  inherit  clause  is  introduced  with  the 
keyword  INHERIT  followed  by  the  name  of  the  module  being  inherited.  The  effect  is 
the  same  as  if  all  the  concepts,  messages,  models  or  states  of  the  inherited  module  were 
copied  verbatim  into  the  current  module.  Any  specific  concept,  message,  model  or  state 
may  be  excluded  from  being  inherited  into  the  current  module  through  a  HIDE  clause. 
To  avoid  name  conflicts,  messages  or  concepts  can  be  "renamed"  to  a  "new"  name  with  a 
RENAME  clause.  [Ref.  13] 

There  are  restrictions  on  which  type  of  modules  can  be  inherited  by  which  other 
types  of  modules.  Defmition  modules  may  only  inherit  other  definition  modules. 
Function  modules  may  inherit  other  functions  and  defmition  modules.  Machine  modules 
may  inherit  other  machines,  function  modules  and  definition  modules.  Type  modules 
may  inherit  other  types,  function  modules  and  defmition  modules.  Any  of  these  four  type 
of  modules  may  inherit  an  instance  module  provided  the  base  module  that  the  instance 
instantiates  is  of  a  type  appropriate  to  the  module  that  is  doing  the  inheriting.  [Ref.  13] 
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A  more  detailed  discussion  of  inheritance  in  Spec  can  be  found  in  [Ref.  13]. 

Closely  related  to  inheritance  is  the  mechanism  for  importing  and  exporting 
concepts  from  one  module  to  another.  Only  CONCEPTS  may  be  imported  and  exported. 
An  IMPORT  clause  is  used  to  allow  concepts  defined  in  other  modules  to  be  made  a 
"part  of  the  current  module.  An  EXPORT  clause  allows  concepts  defined  in  the  current 
module  to  be  available  for  explicit  importation  into  other  modules.  A  concept  cannot  be 
imported  unless  it  has  been  explicitiy  exported  by  the  module  in  which  it  is  defined.  This 
imp>ortation  and  exportation  mechanism,  as  well  as  the  inheritance  mechanism,  is  useful 
for  logical  grouping  of  related  concepts  into  a  single  module  in  support  of  a  modular 
construction  of  large  software  systems.  [Ref.  1,12,13] 

The  SPECDEF  editor  is  able  to  declare  E^^HERTT,  IMPORT,  and  EXPORT 
clauses  for  definition  modules.  However,  there  is  no  capability  for  checking  that  the 
named  module  in  an  INHERIT  clause  exists,  or  whether  a  concept  named  in  an  IMPORT 
clause  has  been  EXPORTed  by  the  named  module.  It  is  therefore  up  to  the  user  to  ensure 
that  such  is  the  case. 

D.  COMPLETE  DESCRIPTION  OF  SPEC 

The  foregoing  discussion  on  Spec  is  necessarily  brief.  For  a  more  thorough 
description  see  [Ref.  12]  and  Chapter  3  of  [Ref.  1].  The  grammar  of  the  Spec  language  is 
included  at  the  end  of  this  thesis  as  Appendix  A. 
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IV.  DESIGN  OF  THE  SYNTAX  DIRECTED  EDFTOR  FOR  SPEC 

A.  GOALS 

1.  Short  Term 

The  initial  shon  term  goals  for  this  research  project  were  as  follows:  (1)  gain  an 
understanding  of  how  to  write  a  specification  for  a  syntax  directed  editor  in  terms  of  the 
Synthesizer  Generator  specification  language,  SSL,  and  (2)  implement  a  working  model 
of  the  syntax  directed  editor  for  a  subset  of  Spec.  In  order  to  achieve  these  goals  as 
quickly  as  possible,  it  was  decided  to  limit  the  specification  to  syntax  editing  only  and 
forego  any  semantic  checking. 

2.  Long  Term 

The  long  term  goals  (beyond  the  scope  of  this  thesis)  are  to  (1)  implement  the 
editor  for  the  complete  Spec  grammar,  and  (2)  integrate  the  editor  into  a  complete 
programming  environment  for  Spec.  This  environment  will  include  the  editor,  a  type 
checker  [Ref.  15],  a  pretty  printer  [Ref  16],  a  consistency  checker,  an  inheritance 
expander,  a  test  oracle,  a  diagram  generator,  and  translator  to  Ada.  With  the  exception  of 
the  pretty  printer  and  an  initial  version  of  both  the  editor  and  the  type  checker,  the  tools 
mentioned  above  have  yet  to  be  developed. 

B.  CONCEPTS  FOR  USING  THE  SYNTHESIZER  GENERATOR 

To  effectively  utilize  the  Synthesizer  Generator,  several  terms  and  concepts  that  are 
perhaps  unfamiliar  to  most  readers  must  be  understood.   An  SSL  editor  specification  is 
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built  around  three  different  but  related  grammars:  the  abstract  syntax  grammar,  the 
concrete  syntax  grammar,  and  the  unparsing  scheme.  The  abstract  syntax  defines  the 
basic  set  of  context-free  grammar  rules  that  define  the  language,  excluding  any  keywords 
in  context  (hence,  context-free).  The  concrete  syntax  defines  the  input  grammar  for  text 
entry,  and  the  productions  of  this  grammar  do  take  keywords  into  account.  The 
unparsing  scheme  defines  the  formatting  rules  for  the  display  representation  of  the 
language,  including  keywords,  punctuation,  and  indentation.  [Ref.  10, 11] 
1.  Attribute  Grammar 

The  Synthesizer  Generator  is  based  on  the  concept  of  an  attribute  grammar.  As 
mentioned  previously,  an  attribute  grammar  is  a  context-fiiee  grammar  that  is  extended  by 
attaching  attributes  to  the  nonterminal  symbols  of  the  grammar  and  by  defining  attribute 
equations  that  determine  the  value  of  those  attributes.  Each  attribute  is  a  piece  of 
information  that  describes  some  semantic  property  of  the  nonterminal.  For  example,  a 
variable  could  have  attributes  such  as  type,  value,  length,  etc.  Each  production  in  the 
grammar  can  have  a  set  of  attribute  equations. 

There  are  two  disjoint  sets  of  attributes  of  a  nonterminal:  synthesized  attributes 
and  inherited  attributes.  Synthesized  attributes  are  associated  with  the  left-hand-side 
nonterminal  of  a  production,  while  inherited  attributes  are  associated  with  nonterminals 
of  the  right-hand-side  of  a  production.  That  is,  the  left-hand-side  synthesizes  its  attribute 
values  from  the  right-hand- side  attributes,  and  the  right-hand-side  inherits  its  attribute 
values  from  the  left-hand-side  attributes.  [Ref.  10:  p.  39] 
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The  current  version  of  the  SPECDEF  editor  defines  only  a  synthesized  attribute  t 
for  some  nonterminals  whose  value  is  the  text  string  entered  to  represent  the  nonterminal. 
Future  versions  of  SPECDEF  may  incorporate  attributes  that  pertain  to  error  messages  or 
other  environmental  factors  related  to  type  checking. 
2.  Abstract  Syntax,  Phyla  and  Terms 

The  underlying  abstract  syntax  of  the  language  is  simply  the  set  of  grammar  rules 
that  define  the  language,  excluding  any  keywords.  In  SSL,  the  abstract  syntax  consists  of 
a  set  of  productions  of  the  form 

Xo  :  op  (X]  X: ...  Xk); 
where  op  is  an  operator  name  and  each  X^  is  a  nonterminal  of  the  grammar.  Each  of 
these  nonterminals  is  the  name  of  a  phylum,  and  each  phylum  is  the  set  of  derivation  trees 
that  can  be  derived  ft"om  the  nonterminal.  A  phylum  is  a  special  kind  of  abstract  data 
type.  The  derivation  trees  are  known  as  terms.  A  term  is  an  expression  that  applies  a  k- 
ary  operator  to  k  elements  of  an  appropriate  phyla.  The  SSL  grammar  rule  acts  the  same 
as  the  context-free  production: 

Xo >  Xj  X2  ...  Xk 

The  operator  serves  to  distinguish  between  rules  that  have  right-hand-sides  that  are 
structurally  identical  but  which  may  have  different  keywords  in  a  concrete  syntax.  For 
example,  the  operator  names  Equal,  Add,  and  Subtract  in  Figure  6  distinguish  between 
three  kinds  of  expression  pairs.  [Ref.  10:  pp.  45-47] 
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root  start; 

start 

optional  list  spec; 

spec 

1 

Spec(spec); 

ModuleNilO 

Module Pair( module  spec) 

1 

rrxxJule 
interface 

DefModuleDecl(interface  concepts); 
lntertaceDecl(formal_name  inherits  Imports  export); 

where 

1 

WhereEmptyO 
WhereExp{expresslonJist) 

> 

optional  list  concepts; 
concepts 

ConceptNilO 
ConceptPair(concept  concepts) 

concept 

ConceptType(formal_name  type_spec  where) 
ConceptValue(formaLname  formal_arguments  where 
formal_arguments  where) 

formal_name 

FormName(identif  ier  formal_parameters) ; 

expression_list 

SingleExp(expression) 
MultiExp(expressionJist  expression) 

expression 

UndefExpO 

Equal(expression  expression) 
Add(expression  expression) 
Subtract(expression  expression) 

identifier 
IDENTIFIER 

Identifier(IDENTIFIER); 
ldentLex<  [a-zA-Z][a-zA-Z_0-9]*  >; 

Figure  6 
Partial  Listing  of  Abstract  Syntax  for  Spec 


The  abstract  syntax  of  a  language  must  have  one  phylum  designated  as  the  root 
phylum.  The  objects  that  can  be  edited  within  the  generated  editor  are  terms  of  this  root 
phylum.  [Ref.  10:  p.  48] 
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3.  Completing  Term 

Each  phylum  has  a  default  value  called  the  completing  term.  The  editor  uses 
these  default  values  at  each  unexpanded  occurrence  of  a  phylum  in  the  derivation  tree  of 
the  object  being  edited.  [Ref.  10:  p.  48] 

The  completing  term  of  a  phylum  is  constructed  by  the  first  operator  declared  for 
that  phylum,  such  as  the  operator  UndefExp  of  phylum  expression  and  the  operator 
WhereEmpty  of  phylum  where  in  Figure  6.  This  completing  operator  is  applied  to  the 
completing  terms  of  its  argument  phyla.  (List  phyla  or  optional  phyla  are  exceptions  to 
this  rule,  as  described  in  Sections  rV.B.5  and  rV.B.6  below.)  [Ref.  10:  pp.48]  For 
example,  the  completing  term  for  phylum  module  defmed  in  Figure  6  is  the  term 

DefModuleDecl(lnterfaceDecl(FormName(...),lnheritNil,lmportNiI,ExportNil),ConceptNil) 
i.e.,  the  completing  operator  for  module  applied  to  the  completing  terms  of  phyla 
interface  and  concepts.  Notice  that  the  completing  term  for  phylum  interface  had  to  be 
constructed  in  the  same  manner  before  the  completing  operator  of  phylum  module  could 
be  applied  to  it. 

4.  Placeholder  Term 

Each  phylum  has  an  associated  placeholder  term  which  is  also  a  default  represen- 
tation for  its  respective  phylum.  The  placeholder  is  used  to  represent  an  "unexpanded" 
node  in  the  derivation  tree  of  the  object  being  edited,  i.e.,  it  represents  a  "to  be 
determined"  value  for  the  respective  phylum.  [Ref.  10:  p.  69] 

Phyla  declarations  may  have  property  declarations  that  determines  the  behavior 
of  the  placeholder  term.    The  propeny  declarations  can  declare  a  phyla  as  an  optional 
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phylum,  a  list  phylum,  or  an  optional  list  phylum.  Any  phylum  that  does  not  have  one  of 
these  declared  properties  is  referred  to  as  an  ordinary  phylum.  For  ordinary  phyla  and 
non-optional  list  phyla,  the  placeholder  term  and  the  completing  term  for  the  respective 
phylum  are  identical.  However,  for  phyla  declared  as  optional  or  an  optional  list,  the 
concepts  are  different  as  explained  in  Sections  IV.B.5  and  IV.B.6.  [Ref.  10:  p.  77] 

The  placeholder  term  often  displays  the  default  representation  of  its  phylum  as  a 
string  of  characters  consisting  of  the  phylum  name  enclosed  in  angle  brackets,  e.g., 
<concept>  or  <identifier>.  Such  a  display  representation  is  not  mandatory,  however. 
For  example,  in  the  SPECDEF  editor,  the  placeholder  term  (and  completing  term)  for 
each  of  the  phyla  field,  type_spec,  and  expression  is  the  symbol  ?,  which  is  the  Spec 
notation  for  an  undetermined  value  that  must  be  defmed  later. 

In  any  case,  the  placeholder  term  is  used  at  an  unexpanded  node  in  the  derivation 
tree.     Even  though  the  derivation  tree  contains  placeholders,  it  is  still  a  complete 
derivation  tree  from  the  system's  point  of  view.  [Ref.  10:  p.  49] 
5.  Lists  and  Optional  Lists 

Certain  phyla  are  designated  as  lists.  A  list  represents  a  sequence  of  items,  such 
as  an  argument  list  in  a  subprogram.  Phyla  declared  as  lists  must  have  exactly  two 
operators,  one  being  a  nullary  operator  and  the  other  a  binary  operator  that  is  right 
recursive.  In  the  example  shown  in  Figure  7,  phylum  StmtLlst  is  declared  as  a  list 
phylum,  with  the  nullary  operator  StmtListNii  and  the  binary,  right  recursive  operator 
StmtListPair.  [Ref.  10:  p.  49] 
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list  stmtList; 

stmtList  StmtListNilO 

I  StmtListPair(stmt  stmtList) 


Figure  7 
Declaring  a  list  phylum 


List  phyla  can  be  declared  as  optional  lists.  Declaring  a  list  as  optional  causes  it 
to  behave  as  a  list  of  zero  or  more  elements,  whereas  a  non-optional  list  behaves  as  a  list 
with  at  least  one  element.  [Ref.  10:  p.  82] 

The  completing  term  for  list  phyla  and  optional  list  phyla  is  defmed  differentiy 
than  for  ordinary  phyla,  for  a  non-optional  list,  the  completing  term  is  constructed  by 
applying  the  binary  operator  to  the  completing  term  of  the  left-argument  phylum  and  to 
the  list's  nullary  operator.  This  has  the  effect  of  concatenating  the  completing  term  of  the 
left-argument  phylum  with  the  nullary  operator  of  the  list  phylum,  resulting  in  a  singleton 
list.  For  optional  list  phyla,  the  completing  term  is  simply  the  constant  term  formed  from 
the  nullary  operator  of  the  phylum.  [Ref.  10:  pp.  77-82] 

The  placeholder  term  for  list  phyla  (whether  optional  or  non-optional)  is  formed 
the  same  as  the  completing  term  had  the  phylum  been  declared  as  a  non-optional  list.  As 
an  example,  the  completing  term  for  phylum  spec  in  Figure  6  is  the  term 

ModulePair(DefModuleDecl(lnterfaceDecl(...),  ConceptNil),  ModuleNil) 
i.e.,  ModulePair  applied  to  the  completing  term  of  phylum  module  and  to  the  term 
ModuleNil.  [Ref.  10:  pp.  79-82] 
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Editors  generated  by  the  Synthesizer  Generator  provide  special  built-in  actions  for 
manipulating  list  phyla.  The  system  command  forward-with-optionals  <'^M  or 
RETURN>  or  forward-preorder  <'^N>  is  used  to  move  the  selection  point  forward  in  a 
derivation  tree  to  the  next  node  in  a  preorder  traversal  (see  Appendix  C  for  information 
on  executing  system  commands).  When  moving  the  selection  through  a  list,  the  editor 
automatically  inserts  a  placeholder  term  before  and  after  each  list  element  If  the  place- 
holder term  is  not  edited  (i.e.,  transformed  through  template  insertion  or  text  entry,  both 
described  later),  when  the  selection  is  moved  to  an  element  that  is  not  contained  within 
the  placeholder  term,  the  placeholder  is  deleted  from  the  derivation  tree.  Because  this 
insertion  and  deletion  process  is  automatic,  these  placeholder  terms  are  referred  to  as 
transient  placeholders.  [Ref.  10:  pp.  69-72] 

The  qualifier  optional  introduces  a  distinction  between  a  phylum's  completing 
term  and  its  placeholder  term.  As  stated  previously,  for  ordinary  phyla  and  non-optional 
list  phyla,  the  completing  term  and  placeholder  term  of  the  respective  phylum  are 
identical.  When  the  current  selection  is  an  optional  list  phylum,  the  completing  term  is 
automatically  replaced  by  the  phylum's  placeholder  term.  If  the  placeholder  term  is  not 
edited  through  template  transformation  or  text  entry  (both  described  later),  and  the 
selection  is  moved  outside  the  scope  of  the  placeholder,  the  placeholder  is  automatically 
replaced  by  the  completing  term.  [Ref.  10:  pp.  76-82] 
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6.  Optional  (Non-List)  Phyla 

Elements  of  the  language  that  are  optional  can  be  declared  as  optional  phyla. 
Optional  list  were  discussed  in  the  previous  section.  Non-list  phyla  can  also  be  declared 
as  optional.  [Ref.  10:  pp.  77-82] 

An  optional  (non-list)  phylum  can  have  any  number  of  operators,  but  one  must  be 
a  nullary  operator.  The  completing  term  of  the  optional  phylum  is  formed  from  the  first 
listed  nullary  operator  of  the  phylum  in  the  editor  specification.  The  placeholder  term  is 
formed  by  "completing"  the  first  operator  of  the  phylum  that  is  not  the  completing-term 
operator.  Since  the  completing  term  is  formed  by  a  nullary  operator,  it  will  contribute 
nothing  to  the  display  representation.  Therefore,  the  order  of  the  operator  declarations 
should  be  arranged  such  that  the  placeholder  term  displays  the  appropriate  prompt,  e.g., 
the  phylum  name  enclosed  in  angle  brackets  or  some  other  appropriate  display  string. 

[Ref.  10:  pp.  79-80] 

7.  Lexical  Phyla 

A  lexical  phylum  is  used  to  declare  special  strings  of  characters  called  lexemes 
that  represent  the  smallest  lexical  units  of  the  language,  such  as  keywords,  punctuation 
and  other  special  characters,  or  literal  constants  such  as  identifiers,  integers,  etc.  The 
three  grammars  that  are  used  in  an  editor  specification  are  interrelated,  and  lexemes  play 
an  important  role  in  these  relationships.  In  the  relationship  between  the  abstract  and 
concrete  grammars,  lexemes  are  used  to  differentiate  between  similar  constructs  during 
semantic  analysis.  It  should  be  noted  that  in  the  concrete  grammar,  certain  lexemes  can 
have  more  than  one  version  or  style.    In  the  unparsing  scheme,  lexemes  are  used  to 
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display  keywords,  punctuation,  other  special  characters  such  as  operator  symbols,  or 
constants.  [Ref.  11:  p.  15] 

Lexemes  are  defined  by  one  or  more  regular  expressions  that  arc  recognized  by 
the  lexical  analyzer  generator  Lex  [Ref.  17].  The  form  of  d  lexeme  declaration  is 

phylum-name  :  lexeme-name  <  regular-expression  >; 
which  declares  that  all  strings  generated  by  the  given  regular-expression  arc  in  the 
named  phylum.  Therc  must  be  at  least  one  blank  separating  the  regular  expression  from 
the  closing  angle  bracket.  The  regular  expression  itself  must  contain  no  embedded  blank 
characters  except  those  explicitly  escaped  by  a  preceding  backslash.  The  lexeme-name  is 
used  in  the  definition  of  the  concrete  input  grammar  to  represent  an  instance  of  the  actual 
lexeme,  such  as  a  keyword  or  special  symbol.  [Ref.  11:  pp.  15-17] 

The   regular   expressions   in    a   lexeme   declaration   are   exacdy   the   regular 
expressions  accepted  by  Lex,  with  only  a  few  exceptions  as  follows  [Ref.  1 1:  p.  16]: 

•  The  blank  character  within  square  brackets  must  be  escaped. 

•  Definitions,  as  described  in  Section  6  of  the  Lex  manual  [Ref.  17],  are  not 
supported. 

In  Figure  8,  "C"  stands  for  any  printable  character,  'W  stands  for  any  decimal 

integer,  and  "£"  stands  for  any  regular  expression.   Each  listing  is  a  regular  expression. 

The  symbols  •'\[]-'^.$?*  +  |()/{}%<>  each  have  special  meaning  in  regular 

expressions  (see  [Ref.  17]  for  full  details).  If  they  are  used  as  literal  text  characters,  they 

must  appear  within  quotation  marks  or  be  escaped  with  a  preceding  backslash.    Inside 

square  brackets,  however,  only  the  characters  \  -  ^  and  blank  have  special  meaning.  All 

other  characters  denote  themselves.  [Ref.  1 1:  pp.  16-17] 
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Expression 

Meaning 

C 

the  character  C 

'CJC2C3' 

the  string  C1C2C3 

\c 

the  character  C 

[CJC2C3] 

the  character  Cj,  C2,  or  C3 

[Cj-Cj] 

any  of  the  characters  from  C;  through  C3 

[^CjC2C3] 

any  character  but  Cj,  C2,  and  Cj 

, 

any  character  but  newline 

^£ 

an  £  at  the  beginning  of  a  line 

£$ 

an  £  at  the  end  of  a  line 

£? 

an  optional  £ 

r 

0  CM-  more  instances  of  £ 

£+ 

1  or  more  instances  of  £ 

£;£2 

an  El  followed  by  an  £2 

f;l^2 

an  £;  or  an  £2 

(E) 

an£ 

EjlE2 

an  E]  but  only  if  followed  by  an  £2 

E(N]A'2) 

N]  through  N:  occurrences  of  £ 

Figure  8 
Construction  of  Regular  Expressions 


Lexeme  declarations  are  not  totally  independent,  since  their  order  can  influence 
the  recognition  process  during  lexical  analysis.  When  more  than  one  regular  expression 
can  be  matched,  the  longest  match  is  made.  If  several  rules  match  the  same  number  of 
characters,  the  declaration  defined  earlier  in  the  specification  is  used.  Because  of  this,  all 
keywords  should  be  defined  prior  to  a  definition  for  a  class  of  identifiers.  [Ref.  11:  pp. 
16-17] 

Whitespace  characters  (spaces,  tabs,  newlines)  are  ignored  during  parsing,  but  are 
important  for  the  concrete  input  syntax.  The  lexeme  declaration 

WHITESPACE:    <[\\n\t]>; 
defines  such  characters  for  the  system.  [Ref.  1 1:  p.  17] 
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C.  PRACTICAL  APPROACH  TO  DESIGNING  AN  EDITOR 

There  are  many  aspects  of  an  editor  specification.  A  novice  editor-designer  will 
probably  be  confused  on  where  to  begin.  The  following  discussion  is  the  recommended 
approach  by  the  authors  of  the  Synthesizer  Generator  together  with  insights  gained 
through  practical  hands-on  experience. 

Start  by  choosing  a  simple  subset  of  the  full  language.  This  allows  the  editor- 
designer  to  become  familiar  with  the  formats  of  the  various  sections  of  the  editor 
specification  without  getting  lost  in  the  details  required  for  the  full  language.  Once  the 
editor  is  implemented  for  this  subset,  and  works  as  expected,  the  subset  can  be  expanded. 
The  remaining  steps  are  listed  in  Table  1  below  and  explained  in  more  detail  in  the  rest  of 
this  section.  [Ref.  10:  pp.  162-169] 

Table  1:  STEPS  TO  DESIGNING  AN  EDITOR  SPECIHCATION 


1 .  Define  the  abstract  syntax. 

2.  Define  the  display  representation. 

3.  Define  template  transformations. 

4.  Generate  and  debug  editor. 

5.  Define  concrete  input  syntax. 

6.  Refine  the  display  representation. 


It  is  recommended  to  design  the  editor  specification  in  a  modular  fashion.  This 
enhances  the  understandability  of  the  editor  specification.  It  also  supports  the  reusability 
of  the  different  "modules"  in  related  editors,  such  as  upward-compatible  editors  for 
language  extensions  or  different  editors  for  the  same  language  that  provide  different 
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display  formats.  Reps  and  Teitelbaum  recommend  [Ref.  10:  pp.  172-178]  the  following 
six  modules  for  organizing  an  editor  specification: 

•  Abstract- syntax  declarations  and  template  transformations  on  these  constructs. 

•  Lexical  declarations. 

•  Concrete-input  syntax  declarations  together  with  precedence  and  associativity 

rules. 

•  Attribute-domain  declarations  and  operations  on  the  attribute  domain.  (Note:  the 
current  version  of  SPECDEF  does  not  have  any  attribute-domain  declarations, 
such  as  environment  attributes.  However,  future  versions  may  need  a  file  with 
these  kinds  of  attributes.) 

•  Attribute  declarations  and  equations, 

•  Unparsing  declarations. 

It  should  be  noted  that  the  above  order  of  modules  does  not  correspond  to  the  order  of 
steps  for  designing  an  editor  specification.     This  is  the  recommended  order  that  the 
respective  SSL  files  should  be  input  to  the  Synthesizer  Generator  to  create  an  editor. 
1.  Define  the  Abstract  Syntax 

The  first  step  is  to  define  the  abstract  syntax  of  the  language  subset   A  Backus- 
Naur   Form    or   context-free    grammar   is   a   convenient   starting   point.      Minimize 
unnecessary  syntactic  distinctions.  For  example,  in  the  production 
exp:  Const(INT); 

the  numerals  007  and  7  will  both  be  translated  to  the  INT  value  7,  and  displayed  as  the 
numeral  7.  If  the  distinction  between  007  and  7  must  to  be  preserved,  however,  the  pre- 
defined phylum  INT  should  be  replaced  by  the  phylum,  say,  INTEGER  with  the  lexeme 
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declaration 

INTEGER:  <  [0-9]+  >; 
which  defines  numerals  as  strings.  Leading  zeros  are  thus  preserved.  [Ref.  10:  p.  163] 

Omit  all  terminal  symbols  that  arc  just  "syntactic  sugar",  such  as  punctuation 
mark?;  and  keywords.  Operator  names  will  suffice  to  distinguish  between  alternative 
tenns  of  the  left-hand-side  phylum.  Only  those  terminals  that  carry  semantic  information 
should  be  retained  in  the  abstract  syntax,  such  as  identifiers,  numerals,  and  other  literal 
constants.  [Ref  10:  pp.  163] 

Attribution  schemes  can  influence  the  design  of  a  language's  abstract  syntax. 
Phrases  that  are  lexically  identical  are  often  used  for  distinct  purposes.  The  static- 
semantic  analysis  then  depends  on  the  context  in  which  the  phrase  is  used.  If  all  usages 
of  the  phrase  have  a  common  syntax,  then  the  context  must  be  passed  down  as  an 
inherited  attribute  to  select  the  appropriate  analysis.  However,  if  each  use  of  the  phrase 
occurs  in  a  different  phylum,  the  context  is  implicit  in  the  phylum's  operators,  and  the 
correct  attribute  equations  for  the  static- semantic  analysis  are  automatically  selected.  It 
is  an  unavoidable  fact  that  the  abstract  syntax  may  have  to  be  changed  when  attribution 
rules  are  addressed.  [Ref  10:  p.  164] 

2.  Define  a  Display  Representation 

The  second  step  in  specifying  an  editor  is  to  defme  an  initial  set  of  unparsing 
declarations  to  allow  the  editor  to  display  the  terms  of  the  abstract  syntax.  Do  not  be 
concemed  with  fancy  pretty-printing  at  this  point.  Defme  only  enough  "syntactic  sugar" 
to  debug  the  abstract  syntax.  Specifically,  do  not  consider  alternative  unparsing  schemes 
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(an  alternate  display  representation  of  the  given  production,  often  used  for  an 
"abbreviated"  display),  optional  line  breaks,  context-dependent  display  formats,  and 
special  fonts  now.  However,  line  breaks  and  simple  indentation  rules  are  advisable  at 
this  stage.  [Ref.  10:  p.  164] 

The  unparsing  declarations  define  which  productions  of  an  object  are  editable  as 
text  as  well  as  the  display  format  of  a  term.  There  is  an  unparsing  production  corre- 
sponding to  each  production  of  the  abstract  syntax.  Each  unparsing  production  consists 
of  a  sequence  of  strings,  names  of  attribute  occurrences,  names  of  right-hand-side 
phylum  occurrences,  and  selection  symbols.  The  unparsing  rules  take  one  of  two  forms: 

phylum  :  operator  [left-side  :  right-side]; 
phylum  :  operator  [left-side  ::=  right-side]; 

The  unparsing  scheme  between  the  square  brackets  represents  a  concrete  display  format 
for  the  corresponding  abstract  syntax  production.  The  symbol  ::=  indicates  the 
production's  text  is  editable,  whereas  the  symbol  :  indicates  the  production  is  (usually) 
treated  as  an  indivisible  structural  unit.  Not  all  operators  of  a  given  production  have  to 
use  the  same  symbol.  The  left-side  is  a  selection  symbol  (explained  below)  representing 
the  left-hand-side  of  the  corresponding  abstract  syntax  production.  The  right-side  is  a 
sequence  of  strings,  attribute-names  and  selection  symbols  representing  the  right-hand- 
side  of  the  corresponding  abstract  syntax  production,  and  defines  the  display  format  for 
that  production.  [Ref.  10:  p.  59] 

Indentation  and  line  breaks  are  indicated  by  the  following  control  characters: 

%t  -  move  the  left  margin  one  indentation  unit  to  the  right 

%b  -  move  the  left  margin  one  indentation  unit  to  the  left 

%n  -  break  the  line  and  move  to  the  left  margin  of  the  next  line 
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These  control  characters  can  be  included  in  strings  (i.e.,  inside  double  quotes)  of  an 
unparsing  rule.  [Ref.  10:  pp.  59-60] 

Each  nonterminal  (i.e.,  phylum  name)  in  an  abstract  syntax  production  is  replaced 
by  the  selection  symbol  @  or  '^  in  the  corresponding  unparsing  rule.  These  selection 
symbols  define  the  selectability  property  for  the  corresponding  node  in  the  tree.  The 
selection  symbol  @  specifies  that  the  phylum  occurrence  is  a  resting  place;  the  selection 
symbol  ^  denotes  a  non-resting  place.  A  resting  place  is  a  point  where  the  corresponding 
phylum  occurrence  can  be  expanded  through  template  insertion  or  text  entry.  Each  node 
in  the  syntax-tree  is  an  instance  of  two  phylum  occurrences  in  the  grammar:  as  a  left- 
hand- side  occurrence  in  one  production,  and  as  part  of  a  right-hand- side  occurrence  in 
another.  If  either  of  its  two  corresponding  occurrences  is  specified  with  an  (§),  that  node 
is  a  resting  place.  [Ref.  10:  p.  61] 

Care  must  be  taken  when  defining  unparsing  schemes  for  list  phyla.  The  two 
occurrences  of  the  list  phylum  (i.e.,  the  left- hand- side  and  the  second  argument  on  the 
right-hand-side)  should  be  defined  with  @  and  the  element-phylum  (the  first  argument 
on  the  right-hand-side)  should  be  defined  with  '^.  This  prevents  an  extra  resting  place  at 
the  element-phylum  position.  Conditional  unparsing  of  list  separators  are  declared  inside 
square  brackets.  These  list  separators  are  suppressed  from  the  display  of  production 
instances  occurring  at  the  end  of  a  list.  For  example,  in  Figure  9,  the  ["%n%n"]  in  the 
unparsing  declaration  for  Module  Pair  cause  each  element  of  the  list  to  be  separated  by  a 
two  line-feeds.  [Ref  10:  p.  61] 
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The  unparsing  declarations  should  initially  contain  the  maximal  number  of  resting 
places  to  allow  full  exploration  and  debugging  of  the  abstract  syntax.  Plan  on  elimi- 
nating undesirable  resting  places  later  by  changing  some  of  the  phyla  occurrences  from 
@to\[Ref.  10:  p.  164] 

Primitive  (lexical)  phyla  occurrences  are  an  exception  to  this  rule--they  should 
not  be  resting  places.  This  has  the  effect  of  forcing  the  resting  place  one  node  higher  in 
the  tree.  To  see  why  this  is  useful,  imagine  the  following  situation  based  on  the  abstract 
syntax  and  unparsing  rules  for  a  desk  calculator  depicted  in  Figure  10.  Suppose  the 
selection  is  positioned  at  an  occurrence  of  phylum  INT  in  one  of  the  desk  calculator's 
expressions.  The  pre-defined  primitive  phylum  INT  has  a  placeholder  term  of  0,  which 
would  replace  the  selection  if  the  command  delete-selection  <^K>  were  executed  and 
INT  was  a  resting  place.  But  if  INT  is  not  a  resting  place,  the  selection  is  forced  one 
level  higher  to  Const(INT).  Now  if  the  command  delete-selection  is  executed,  the 
placeholder  term  for  exp,  namely  Null,  replaces  the  selection.  The  display  representation 
for  Null  is  the  string  <exp>.  [Ref.  10:  pp.  163-165] 

Since  occurrences  of  primitive  phyla  are  not  resting  places,  in  operators  of  arity 
two  or  more,  the  primitive  phyla  occurrences  will  not  be  individually  selectable. 
Therefore,  an  extra  syntactic  level  is  necessary  to  allow  the  individual  selection  of 
components.  Failure  to  add  this  extra  level  is  a  common  mistake  made  when  designing 
an  editor  specification.  [Ref.  10:  p.  165] 
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start 

Spec 

I@ 

:@] 

spec 

:            ModuleNil 
Module  Pair 

[@ 

::-= ''  [-%n%nT  @] 

module 

Def  Module  Decl 

I@ 

::-  -DEFINITION  "  @  @  -%n- 
-ENDT 

interface 

Interface  Decl 

[@ 

::=  @  -%t%n"  @  "%n"  @  -%n"  @  "%b%nT 

where 

WhereEmpty 
WhereExp 

I@ 

::=  "WHERE "  @] 

corrcepts 

ConceptNil 
ConceptPair 

[@ 

::=  ^  ["%n"]  @] 

concept 

1 

ConceptType 
ConceptValue 

l@ 
[@ 

::=  -%t%n""CONCEPT  "  @  " : "  @  "%t%n" 

@  ""/obrobyon"] 
::=  "%t%n""CONCEPT  "  @  @  "%t%n" 

@  "%n" 

"VALUE  "  @  "%n"  @  "%b%b%n"] 

formal_name  : 

1 

FormName 

[@ 

:=  @  "  -  @] 

expression_list 

SingleExp 
MuttiExp 

[@ 
[@ 

>  @  ", "  @] 

expression 

UndefExp 
Equal 
Add 
Subtract 

1(3) 
[@ 
[@ 

:= "?"] 

:=  @  -  -  "  @] 
:=  @  "  -t- "  @] 
:=  @  "  - "  @] 

identifier 

» 

Identifier 

[@ 

>1 

Figure  9 
Partial  Listing  of  Spec  Unparsing  Declarations 
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root  calc; 

list  calc; 

calc 

CalcNIlO 

CalcPair(exp  calc)                                                                                   1 

exp 

NullO 

Sum,  Diff,  Proc 

1,  Quot(exp  exp) 

1 

Const(INT) 

calc 

CalcPair 

I@: 

:-  @  "%nVALUE  -  ??r;%n%n"]@]; 

exp 

Null 

l@: 

>  "<exp>T 

1 

Sum 

l@: 

> "("  @  -  +  ■  @  -)T 

1 

DIff 

(@: 

>T@"-"@"n 

1 

Prod 

l@: 

>T@"*"@"n 

1 

Quot 

[@: 

:=  -(-  @  "  /  -  @  -)-] 

1 

Const 

[@: 

^'^l 

Figure  10 
Desk  Calculator  abstract  syntax  and  unparsing  rules 


3.  Define  Template  Transformations 

The  third  step  in  designing  an  editor  specification  is  to  provide  a  set  of  transfor- 
mation declarations,  or  template  transformations  to  restructure  an  object  when  the  current 
selection  is  a  placeholder.  The  purpose  of  a  template  transformation  is  to  replace  the 
placeholder  term  with  the  template  of  one  of  the  other  productions  of  the  respective 
phylum.  The  form  of  a  transformation  declaration  is 

transform  Xq  on  transformation-name  <Xo>  :  operator  {<Xj>,...,<X„>)\ 
which  corresponds  to  the  abstract  syntax  production 

Xo  :  operator  (X]..Xn) 
Each  <X,>  denotes  the  placeholder  term  of  the  phylum  X,.  [Ref.  10:  p.  166] 
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As  with  other  kinds  of  SSL  declarations,  the  phylum  name  Xq  can  be  factored  to 
the  left  when  there  are  multiple  transformations  on  the  same  phylum  [Ref.  1 1:  p.  86]: 

transform  Xq 

on  transformation- name 2  <Xo>  :  operator j  (<X7>,...,<^«>), 
on  transformation- name2  <Xo>  :  operatorj  {<Yi>,.,.,<Y^>), 

on  transformation-name  1^  <Xo>  :  operator^  (<Z7>,...,<Z„>) 

» 

The  transformation-name  is  enclosed  in  double  quotes  and  constitutes  command 
that  can  be  invoked  to  replace  the  placeholder  term  with  the  invoked  template  (sec 
Appendix  C  for  information  on  invoking  template  transformations).  Figure  11  is  a  partial 
listing  of  the  template  transformations  for  Spec. 

List  phyla  and  optional  phyla  do  not  normally  require  template  transformations. 
Commands  that  move  the  selection  (e.g.,  forward-with-optionals  ['^M  or  RETURN]  and 
forward-sibling-with-optionals  [ESC-'^M])  provide  adequate  transformations  for  these 
phyla.  [Ref.  10:  p.  166] 


transform  concept 

on  "type"  <concept>:        ConceptType(<formal_name>,<type_spec>,<where>), 

on  "value"  <concept>:        ConceptValue(<formaL'Tanie>,<formal_arguments>, 

<where>,<fomTal_arguments>,<where>) 

transform  expressionjist 

on  "single"         <expressionJist>:  SingleExp(<expression>), 

on  "multiple"      <expression_list>:  MuftiExp(<expression_list>,<expresslon>) 


transform  expression 

on  "="  <expression> 

on "+"  <expression> 

on "-"  <expresston> 


Equal(<expression>,<expression>), 

Add(<expression>,<expresslon>), 

Subtract(<expression>,<expresslon>) 


Figure  11 
Partial  Listing  of  Spec  Template  Transformations 
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4.  Generate  and  Debug  Editor 

At  this  stage  the  partial  editor  specification  defines  enough  of  the  editor's 
structure-editing  facilities  to  allow  the  Synthesizer  Generator  to  create  an  editor  and  for 
you  to  test  the  editor's  characteristics.  Invoke  sgen  on  the  specification  files.  By 
default,  the  created  editor  will  be  placed  in  the  file  syn.out.  This  can  be  overridden  with 
the  -0  option  which  allows  the  user  to  declare  what  filename  the  editor  will  be  called. 
[Ref.  10:  p.  167] 

Recommended  options  to  include  at  this  point  are  the  -w  window-system-name 
window  option,  which  specifies  that  the  editor  will  be  created  for  the  specific  window- 
sy stem-name,  and  the  -v  option,  which  invokes  Yacc  [Ref  18]  with  the  -v  flag  so  the 
diagnostic  file  y. output  will  be  produced.  This  file  is  useful  for  debugging  the 
specification  file.  [Ref.  10:  p.  288] 

The  y. output  file  produced  by  Yacc  is  a  complete  listing  of  the  state  machine 
model  that  represents  the  created  editor.  If  there  are  any  parsing  conflicts  in  the  editor 
specification,  these  can  be  located  in  the  y. output  file  by  loading  it  into  the  vi  editor  and 
doing  a  search  for  the  word  conflict.  Specifically,  the  types  of  conflicts  that  can  occur 
are  shift/reduce  and  reduce/reduce  conflicts,  both  of  which  are  described  in  detail  below. 

5.  Define  Concrete  Input  Syntax 

Next,  define  the  concrete  syntax  for  textual  input.  The  concrete  syntax  consists  of 
lexical  declarations,  parsing  declarations,  and  correspondence  rules  for  connecting  the 
concrete  syntax  and  the  abstract  syntax.    Initially,  provide  only  those  rules  needed  to 
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permit  entering  lexemes  and  simple  expressions.    The  rules  can  be  elaborated  later  to 
permit  text  entry  for  additional  language  constructs.  [Ref.  10:  p.  167] 

The  term  text  editing  refers  to  the  process  of  modifying  the  textual  representation 
of  an  object  through  operations  on  the  character  sequence  [Ref.  10:  p.  108].  Structure 
editing  is  the  process  of  nxxiifying  the  underlying  abstract  syntax  tree  structure  of  an 
object  [Ref.  10:  p.  95]. 

Text  editing  is  more  appropriate  than  structure  editing  for  entering  and  modifying 
expressions.  It  is  also  needed  for  entering  identifiers.  While  a  subterm  is  being  edited, 
the  usual  rigors  of  the  syntax  directed  discipline  are  temporarily  suspended,  since  the 
subterm  being  edited  can  be  any  string  whatsoever.  When  the  editing  is  complete,  the 
string  is  parsed  and  translated  to  the  corresponding  term  of  the  abstract  syntax.  [Ref.  10: 
p.  62] 

a.  Parsing  Declarations 

The  parsing  declarations  that  define  the  concrete  input  syntax  are  distin- 
guished from  the  other  phylum  and  operator  declarations  of  an  SSL  specification  by 
using  the  symbol  ::=  instead  of  :  to  separate  the  left-hand-side  phylum  name  from  the 
right- hand- side  symbols.  Additionally,  parsing  declarations  may  have  tokens  (single 
characters  enclosed  in  quotes)  interspersed  among  the  phylum  symbols  on  the  right-hand- 
side. 

Each  parsing  declaration  has  the  form: 
phylum-name  .;=  operator-name  (tokens phylum i  tokens phylum2  ...phylumk  tokens); 
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Some  of  the  phylum^  may  be  lexical  phyla  that  defme  keywords  or  other  multi-character 
tokens.  Knowing  which  string  occuired  in  the  input  is  usually  relevant.  Therefore,  the 
corresponding  string  appears  as  the  /-th  argument  of  the  operator  in  the  parse  tree. 
Examples  of  parsing  declarations  are  shown  in  Figure  12.  [Ref.  11:  pp.  76-77] 

Attribute  equations  for  constructing  terms  from  text  input  arc  combined  with 
the  parsing  declarations  using  the  following  syntax: 

phylum-name  ::=  operator-name  (parsing-scheme)  {equations}; 
Synthesized  attributes  of  the  left-hand-side  phylum  and  inherited  attributes  of  the  right- 
hand- side  phylums  are  termed  the  production's  output  attributes.  An  attribute  equation 
defines  the  value  of  an  output  attribute  in  terms  of  other  attributes  accessible  within  the 
production.  The  attribute  equation(s)  are  grouped  inside  curly  braces.  An  output 
attribute  b  of  phylum  X  is  denoted  by  X.b.  If  there  is  more  than  one  occurrence  of 
phylum  name  X  in  an  attribute  equation,  the  various  occurrences  of  b  are  denoted  (from 
left  to  right)  by  X$^.b,  X$2.b,  etc.  An  attribute  ft  of  a  left-hand-side  phylum  of  a 
production  can  be  denoted  by  $$./?.  [Ref.  11:  pp.  27-28] 

Examples  of  attribute  equations  are  shown  in  Figure  13.  In  the  attribute 
equations  for  SPECDEF,  the  attribute  t  is  for  text.  As  an  example  of  how  the  attribute 
equations  work,  let's  examine  the  equation  for  phylum  FormalName.  The  text  attribute 
for  FormalName  is  given  the  value  formed  by  applying  the  abstract  syntax  operator 
FormName  to  the  value  of  the  text  attributes  of  the  concrete  input  phyla  Ident  and 
FormalPami. 
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Module 
Interface 

::-=  (DEFINITION  Interface  Concepts  END); 
:>  (FomnalName  Inherits  Imports  Export); 

Concepts 

::=  (Concept) 

1     (Concept  Concepts) 

t 

Formal  Name 
Formal  Parm 

::=  (Idem  FormalParm); 
1     (•{•  Field-ist '}'  Where) 

1 

Idem 

::-  (IDENTIFIER): 

Figure  12 
Concrete  Syntax  Parsing  Declarations 


The  format  of  attribute  equations  for  list  phyla  is  different.  Examine  the 
attribute  equations  for  phylum  Concepts  in  Figure  13.  For  the  first  production,  the  text 
attribute  of  Concepts  is  given  the  value  formed  by  concatenating  the  value  of  the  text 
attribute  of  phylum  Concept  with  the  nullary  term  ConceptNil.  For  the  second 
production,  the  new  value  of  the  text  attribute  of  phylum  Concepts,  designated  on  the 
left-hand- side  as  ConceptS$1  .t,  is  given  the  value  formed  by  concatenating  the  value  of 
the  text  attribute  of  the  phylum  Concept  with  the  previous  value  of  the  text  attribute  of 
phylum  Concepts,  designated  on  the  right-hand-side  as  Concepts$2.t.  Recall  that 
multiple  occurrences  of  a  phylum  name  X  within  an  attribute  equation  are  differentiated 
left  to  right  as  X$1 ,  X$2,  etc. 
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Module 

:;=  (DEFINITION  Interface  Concepts  END) 

{Modde.t  =  DefModuleDed(lnterface.tConc8pts.t);) 

Interface 

::=  (FormalName  Inherits  Imports  Export) 

{IntBrtece.t  >  lnter1aoeDeci(FormalName.t.lnherits.t, 
Imports.t.Exportt);) 

Concepts 

::=  (Concept)           {Concepts.!  =  (Concept! ::  ConoeplNiO;} 
1     (Concept  Concepts) 

{Conc©pts$1  t  =  (Concept.t ;:  Conc«pt»$2.t);) 

Formal  Name 

:>  (Ident  FonnalParm) 

^Formd^4ame.t  -  FofmN«ne(ldenLtForma»Parm.t);} 

FonnalParm 

::=  0                        {$$.t  =  FomialParmEmptyO;} 
1     (■{•  ReldUst  r  Where) 

{FormalParm.t  =  FormalParmUst(FieldLisLt,Where.t);l 

Ident 

::=  (IDENTIFIER)      {Ident.t  =  ldentif(er(IDENTIFIER);) 

Figure  13 
Parsing  Declarations  with  Attribute  Equations 

The  operator  names  of  parse  tree  terms  are  optional,  and  usually  are  not 
needed  since  the  parser  constructs  the  parse  tree.  A  unique  operator  name  is 
automatically  generated  by  the  parser.  [Ref.  1 1:  p.  78] 

b.  Correspondence  Between  Concrete  Syntax  and  Abstract  Syntax 

To  translate  from  text  to  term,  rules  are  needed  that  define  the  association 
between  the  abstract  syntax  and  the  concrete  input  syntax,  along  with  attribute  equations 
that  synthesize  the  term  as  an  attribute  of  the  parse  tree.  These  rules  are  associated  with 
the  productions  of  the  concrete  syntax,  which  is  thus  extended  to  become  an  attributed 
grammar  which  generates  terms  of  the  abstract  syntax.  [Ref.  10:  p.  62] 

Attributes  must  be  defmed  with  an  attribute  declaration  which  has  the  form 
concrete-syntax-phylum  [  synthesized  abstract-syntax-phylum  attribute-name;]; 
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Examples  of  attribute  declarations  are  shown  in  Figure  14.  Note  that  the  reserved  word 
synthesized  can  be  abbreviated  as  syn.  [Ref.  11:  pp.  24-25] 

A  convenient  convention  for  naming  the  concrete  syntax  phylum  is  to  use  the 
same  name  as  the  corresponding  abstract  syntax  phylum  and  capitalize  the  first  letter  of 
each  "word"  within  the  name  (e.g.,  FormalName).  Occasionally  you  may  have  to  invent 
some  other  name  if  such  a  capitalized  name  has  already  been  used,  for  example,  as  an 
operator  in  the  abstract  syntax  declarations.  Attribute  names  are  often  abbreviated  words 
or  phrases  that  are  descriptive  of  what  kind  of  attribute  they  are  naming  (e.g.,  t  for  text, 
env  for  environment,  etc.)  [Ref.  11:  p.  9;  10:  p.  63] 

Entry  declarations  establish  the  correspondence  between  selections  in  the 
abstract  syntax  and  entry  points  within  the  concrete  input  syntax.  Each  entry  declaration 
has  the  form: 

abstract-syntax-phylum  ~  concrete-syntax-phylum.attribute-name; 
This  declaration  specifies  that  when  the  current  selection  in  the  abstract- syntax  tree  is  a 
node  of  phylum  abstract-syntax-phylum,  the  input  is  parsed  according  to  the  parse  declar- 
ations of  concrete-syntax-phylum,  and  the  value  of  attribute  concrete-syntax- 
phylum.attribute-name  is  insened  into  the  abstract- syntax  tree,  replacing  the  currently 
selected  subterm  or  sublist.  Figure  14  is  a  partial  listing  of  text  attribute  declarations  and 
entry  declarations  for  Spec.  [Ref.  10:  pp.  62-65;  1 1:  pp.  74-76] 
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Module 

{  syn  module  t; }; 

Interface 

{ syn  Interlace  t;}: 

Where 

{  syn  where  t; }; 

Concepts 

{  syn  concepts  t; }; 

Concept 

{  syn  concept  t; }; 

Formal  Name 

{ synfomial_namet;}; 

ExpLlst 

{  syn  expression Jist  t; }; 

Exp 

{  syn  expression  t; }; 

Idem 

{ synidenttfiert;}: 

nxKJule 

Module.t; 

interface 

Interface.t; 

where 

Where  .t; 

concepts 

Concepts. t; 

concept 

Concept.t; 

formal_name 

Formal  Name.t; 

expression_list 

ExpList.t; 

expression 

Exp.t; 

identifier 

Ident.t; 

Figure  14 
Association  Between  Abstract  Syntax  and  Input  Syntax 

c.  Concrete  Lexical  Declarations 

Lexical  phyla  should  be  declared  for  each  keyword  and  other  multi-character 
token  of  the  language.  A  declaration  for  the  special  token  WHITESPACE  should  be 
included  at  this  point  if  it  has  not  been  previously  declared.  Examples  of  lexical 
defmitions  are  shown  in  Figure  15.  [Ref.  10:  p.  167] 
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WHITESPACE: 

AND: 

OR: 

NOT: 

WhiteSpace<[\\t\n]*>; 
AndLex<  "&"  >; 
OrLex<  "1"  >; 
NotLex<  "~"  >; 

CONCEPTS: 
DEFINITION: 
END: 

ConceptLex<  "CONCEPr  >; 
DefnLex<  "DEFINITION"  >; 
EndLex<  "END"  >; 

SEMI: 
PLUS: 
MINUS: 

SemiLex< ";"  >; 
PlusLex< "+-  >: 
MlnusLex< "-"  >; 

INTEGER  LIT: 
IDENTIFIER: 

lntegerLex<[0-9]+>; 

ldentLex<  [a-2A-Zl[a-zA-Z_0-9]*  >; 

Figure  15 
Lexical  Definitions 


d.  Parsing  and  Ambiguities 

The  Synthesizer  Generator  uses  the  parser  generator  Yacc  [Ref.  18]  to  create 
the  editor's  parser.  As  the  parser  scans  the  input  stream,  it  pushes  and  pops  tokens 
onto/from  a  stack  according  to  the  parsing  declarations.  A  shift  pushes  the  next  token  a 
onto  the  stack;  a  reduce  pops  tokens  off  the  stack  when  all  tokens  necessary  to  complete 
a  parsing  rule  have  been  seen.  The  resulting  token  (an  occurrence  of  the  left-hand-side  of 
a  parsing  declaration)  is  then  pushed  onto  the  stack  before  the  next  token  a  is  parsed. 

Yacc  will  detect  and  report  any  ambiguities  in  the  input  grammar.  Ambigu- 
ities are  of  two  types:  a  shift/reduce  conflict  or  a  reduce/reduce  conflict.  A  shift/ reduce 
conflict  arises  when  the  parser  cannot  determine,  based  on  the  stack  contents  and  the  next 
token  a,  whether  to  apply  a  reduction  rule  or  to  shift  a  onto  the  stack,  thereby  deferring 
the  reduction.   A  reduce/ reduce  conflict  arises  when  the  parser  can  apply  more  than  one 


55 


reduction  rule  to  the  current  contents  of  the  stack.    By  default,  Yacc  resolves  these 

conflicts  as  follows: 

•  For  a  shiftA"educe  conflict,  perform  the  shift. 

•  For  a  reduce/reduce  conflict,  reduce  by  the  production  declared  earliest  in  the 
specification. 

These  resolution  rules  will  often  not  do  what  you  intended.  Therefore,  some  additional 

mechanism  is  required  to  resolve  ambiguities.  [Rcf.  1 1:  p.  79] 

Precedence  declarations  provide  this  additional  mechanism  for  resolving 

ambiguities  in  the  input  grammar.  They  must  be  listed  prior  to  the  parsing  declarations. 
These  precedence  declarations  associate  precedence  levels  with  characters  and  lexemes. 
There  are  tliree  forms  of  precedence  declarations: 

left  token-or-phylum],...,token-or-phyliunk', 

right  tok£n-or-phylumi,...,token-or-phylumk', 

nonassoc  token-or-phylumj,...,token-or-phylemk', 

Each  token- or-phylum  can  be  a  single  CHAR  constant,  such  as  '+',  or  the 
name  of  a  lexical  phylum,  such  as  IDENTIFIER.  The  same  precedence  level  and 
associativity  is  assigned  to  all  characters  and  lexemes  denoted  by  token-or- 
phylum],...,token-or-phylumk.  The  order  in  which  precedence  declarations  are  listed  in 
the  SSL  specification  is  extremely  important— each  successive  declaration  receives  a 
higher  precedence  than  the  previous  declaration(s)  (i.e.,  precedences  are  declared  low-to- 
high).  The  keywords  left,  right,  and  nonassoc  defme  the  associativity  of  the  listed 
tokens.  The  effects  of  precedence  and  associativity  arc  described  below.  [Ref.  1 1:  p.  79] 

The  final  token  in  a  concrete  syntax  production  determines  the  precedence 
level  and  associativity  of  the  production.  Precedences  and  associativity  can  be  associated 
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with  complete  productions  as  well  as  with  tokens.  To  assign  an  explicit  level  of 
precedence  to  a  production,  which  could  be  either  the  same  as  or  different  than  the 
precedence  level  of  the  last  token  (if  one  is  present  at  all),  the  parsing  declaration  uses  the 
form: 

phylum-name  ..=  operator- name  (list-of-tokens-and-phyla prec ioken-or-phylum); 
Yacc  uses  these  precedence  rules  to  disambiguate  the  productions  of  the  input  grammar 

as  follows: 

•  When  there  is  a  reduce/reduce  conflict,  or  there  is  a  shift/reduce  conflict  and 
either  the  input  symbol  (i.e.,  character  or  lexeme  name)  or  the  grammar  rule  has 
no  precedence  and  associativity,  the  disambiguation  rules  stated  above  are 
applied  and  the  conflicts  reported. 

•  If  there  is  a  shift/reduce  conflict,  and  both  grammar  rule  and  input  character  have 
precedence  and  associativity,  the  conflict  is  resolved  in  favor  of  the  action  (shift 
or  reduce)  associated  with  the  higher  precedence.  If  precedences  are  the  same, 
associativity  is  used:  left  associative  implies  reduce;  right  associative  implies 
shift;  nonassociating  implies  error. 

Using  the  -v  option  of  sgen  is  extremely  helpful  in  debugging  such  conflicts.    The 

y.output  file  generated  by  Yacc  will  indicate  aU  shift/reduce  and  reduce/reduce  conflicts 

and  which  tokens  caused  them.   After  running  sgen,  edit  this  file  and  perform  a  search 

for  the  word  "conflict".  [Ref.  11;  p.  80] 

Figure  16  is  a  partial  listing  of  the  lexical  phyla,  precedence  declarations,  and 

concrete  syntax  parsing  declarations  for  SPECDEF. 
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r  lexical  phyla  * 

1 

WHITESPACE; 

WhiteSpace<I\\t\n]*>; 

CONCEPT: 

ConceptLex<  "CONCEPr  >; 

DEFINITION: 

DefnLex<  -DEFINITION-  >; 

END: 

EndLex<  'END-  >; 

VALUE: 

ValueLex<  'VALUE-  >; 

WHERE: 

WhereLex<  -WHERE"  >; 

SEMI: 

SemiLex< ";-  >; 

COMMA: 

Commaljex<  ■.*  >; 

PLUS: 

PlusLex<  ■+•  >; 

MINUS: 

MinusLex<  --"  >; 

/*  precedence  and  associativity  rules  */                                                                                                                              | 

left        •;■  SEMI 

IDENTIFIER; 

left        '.■  COMMA;                                                                                                                                                            | 

left        •=•; 

left        •+•  •-•  PLUS  MINUS; 

r  concrete  input  syntax  */ 

Module 

::=  (DEFINITION  Interface  Concepts  END) 

{Module. t  =  DefModuleDecl(lnterface. t. Concepts  t);) 

Interface 

::=  (FormalName  Inherits  Imports  Export) 

{Interface.t  =  lnterfaceDecl(FormalName.t,lnherits.t,lmports.t,Export.t);) 

Where 

::=  (prec  SEMI)                         {$$  t  =  WhereEmpty();) 

1     (WHERE  ExpList)               {Where.t  =  WhereExp(ExpUstt);) 

Concepts 

::=  (Concept)                            {Concepts. t  =  (ConcepLt ::  ConceptNil);) 

1     (Concepts  Concept)            {Conc8pts$1  t  =  (Concept. t ::  Concepts$2.t);) 

Concept 

::=  (CONCEPT  FormalName  :■  TypeSpec  Where) 

(Conceptt  =  ConceptType(FonmalName.t,TypeSpec.t,  Where.t);} 

1     (CONCEPT  FormalName  FomialArg  Where  VALUE  FormalArg  Where) 

{Concept  t  =  ConceptValue(FormaJName.tFormalArg$1.t,Where$1.t, 

Fomial  Arg$2  .t  WhefB$2.t) ;} 

FormalName 

::=  (Ident  FormalParm)             {FormalName  t  =  FormNani>«(ldent  t.FormalPanm.t);) 

ExpList 

;  =  (Exp  prec  COMMA)                             {ExpListt  =  SingleExp(Exp  t);} 

1     (ExpList '.'  Exp  prec  COMMA)             {ExpList$1.t  =  MultiExp(ExpList$2.t,Exp.t);} 

Exp 

:  :=  (?)                                                     lExp.t  -  UndefExp{):} 

1     (Exp  •=■  Exp  prec  •=•)           {Exp$1.t .  EquaKExp$2.t,Exp$3.t);} 

1     (Exp  •+•  Exp  prec  PLUS)      (ExpSl.t  =  Add(Exp$2.t,Exp$3.t);} 

1     (Exp  ■-•  Exp  prec  MINUS)    {Exp$1.t  =  Subtract(Exp$2.t,Fxp$3.t);} 

Ident 

::=  (IDENTIFIER)      {Ident.t  =  ldentifier(IDENTlFIER);} 

Figure  16 

Lexical  Phyla,  Precedence  and  Associativity  Rules,  and 

Concrete  Input  Syntax  Parsing  Declarations  for  SPECDEF 
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6.  Refine  the  Display  Representation 

The  final  step  to  complete  the  initial  version  of  the  editor  specification  is  to  refine 
the  display  representation.  In  Section  IV.C.2  we  suggested  that  the  unparsing  declar- 
ations be  written  with  the  maximal  number  of  resting  places.  Any  undesirable  resting 
places  should  now  have  their  selection  symbol  changed  from  @  to  '^.  It  is  very  important 
that  the  selection  symbols  in  lists  are  defined  according  to  the  pattern  shown  in  Figure  17 
because  selections  in  lists  are  handled  specially.  [Ref.  10:  p.  171] 


abstract  syntax  rule 

ListTypeNuIK) 
ListTypePair(listElement  listType) 

unparsine  rule 

list  listType; 
listType 

1 

[@::=] 
[@  ::=  ^  @] 

listElement 

ListElementNullO 

[^  ::=  '•<listEle 

Figure  17 
Unparsing  pattern  for  list  phyla 


For  example,  the  unparsing  declarations  shown  in  Figure  9  should  be  changed  to 
have  some  of  the  selection  symbols  on  the  left-hand-side  of  the  unparsing  rules  changed 
from  @  to  '^  as  shown  in  Figure  18. 

Finally,  the  editing-mode  symbols  in  the  unparsing  declarations  (i.e.,  the  ::=  and  : 
symbols)  need  to  be  checked  that  they  specify  the  desired  text-editing  properties  for  the 
various  operators.  Specifically,  if  the  operator  allows  text  entry,  the  ::=  symbol  should  be 
used,  but  if  text  entry  or  text  re-editing  is  not  allowed,  the  :  symbol  should  be  used.  Note 
that  the  symbol  ::=  also  allows  textual  re-editing  of  elements.  Therefore,  if  the  designer 
wanted  to  allow  the  entry  of  individual  lexemes  but  not  full  expressions,  the  unparsing 
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rules  for  the  phylum  expression  should  be  changed  from  what  was  shown  in  Figure  18 
to  those  shown  in  Figure  19.  [Ref.  10:  p.  172] 


start 
spec 

module 

interface 

where 

concepts 

corrcept 


formal  name  : 


expression_list: 


expression 


identifier 


Spec 

ModuleNil 
ModulePaIr 

Def  Module  Decl 


Interface  Decl 

WhereEmpty 
WhereExp 

ConceptNil 
ConceptPair 

ConceptType 

ConceptValue 

FormName 


SingleExp 
MultiExp 

UndefExp 
Equal 
Add 
Subtract 

Identifier 


I@:@] 

[@  ■■■■'] 

[@  ::-  *  [■•%n%nT  @] 

[@  ::-  -DEFINITION  "  @  @  "%n- 
"END") 

(@  ::-  @  ••%t%n"  @  "%n"  @  "%n-  @  -%b%nT 


[^::=  "WHERE -@] 

l@  ::=  1 

I@  ::=  ^  ["%n"]  @] 

["  ::=  "%t%n"-CONCEPT "  @  " : "  @  "%t%n" 

@  -%b%b%n-] 
["  ::=  -%t%n""CONCEPT  "  @  @  "%t%n" 

@  "%n" 

"VALUE "  @  "%n"  @  "%b%b%n"] 


[' 

:=@""@1 

[^ 
r 

:=  @  ", "  @] 

:= "?"] 

:=  @  "  -  "  @] 
:=  @  -  +  -  @] 

r::-'^] 


Figure  18 
Refined  Unparsing  Declarations  for  Spec 
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expression  UndefExp 

I  Equal 

I  Add 

Subtract 


[^ 

:> "?"] 

l^ 

:@-  =  "@] 

I'^ 

:  @  "  +  "  @] 

l^ 

:  @  "  - "  @] 

Figure  19 
Unparsing  rules  that  forbid  re-editing 

7.  Advanced  Unparsing  Features 

We  have  already  discussed  the  use  of  the  control  strings  %t,  %b  and  %n  in 
unparsing  declarations  to  signal  tab,  backtab,  and  new  line,  respectively.  It  should  be 
noted  that  changing  the  left-margin  (i.e.,  with  %t  or  %b)  has  no  immediate  visible  effect. 
The  change  is  only  evident  after  the  start  of  a  new  line.  [Ref.  1 1 :  p.  64] 

To  prevent  the  undesirable  effect  of  having  long  lines  of  display  text  broken  in 
mid- word,  optional  line  breaks,  indicated  by  %0,  provide  the  means  to  specify  places 
where  a  term's  display  string  may  be  divided  into  separate  lines.  The  designer  can 
impose  a  hierarchical  structure  on  the  display  string  by  the  matched  grouping  symbols 
%{  and  %}.  The  editor  will  attempt  to  spht  long  lines  containing  optional  line  breaks  in 
such  a  way  that  the  minimum  number  of  unparsing  groupings  will  be  split  and  the 
amount  of  text  on  the  line  is  maximized.  A  grouping  only  has  effect  if  it  contains  an 
optional  line  break.  If  indentation  is  desired  only  for  the  text  that  follows  an  optional  line 
break  that  is  taken,  the  formatting  command  string  %t%0%b  may  be  used.  A  complete 
listing  of  unparsing  display  commands  is  shown  in  Figure  20.  [Ref.  1 1:  pp.  63-66] 
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Formatting 

Command 
%t 

Meaning 

move  the  left-margin  one,  indentation  unit  to  die  right 

%b 

move  the  left-margin  one  indentation  unit  to  the  left 

%n 

bnvik  the  line  and  return  to  the  current  left-margm 

%l 

return  to  current  left-margin  of  the  samt  line  and  overprint 

%1 

move  to  column  one  of  the  same  line  and  ovnprint 

%T 

move  right  to  the  ne«  tab  stop 

%M(c) 

move  right  to  column  c,  where  c  is  a  positive  integer 

%0 

optionally,  In^ak  the  line  and  return  to  the  current  left-margin 

%C 

same  as  %0,  but  either  all »  no  %C  in  a  group  are  taken 

%{ 

begmmng  of  an  unparsing  group 

%} 

end  of  an  unparsing  group 

%( 

same  as  %t%{ 

%] 

same  as  %}%b 

"/oSistyle-name: 

enter  the  named  style 

%S) 

revert  to  the  previous  style 

%% 

display  a  % 

Figure  20 
Formatting  Commands 


To  see  how  some  of  these  commands  can  be  used,  let's  look  at  an  example  of  an 
unparsing  declaration  that  includes  groupings  and  optional  line  breaks.  The  following 
declaration  uses  the  formatting  commands  for  beginning  and  end  of  an  unparsing  group, 
beginning  and  end  of  an  unparsing  group  with  tabs  and  backtabs,  and  optional  line 

breaks: 

expression  :  QuanlifierExp     [^  ::=  "%{"  @  "("  @  "%o"  @  "%}%I%o  :: "  (3)  ")%n 

The  resulting  expression  could  be  displayed  in  several  formats  that  would  be  dependent 

on  the  width  of  the  current  window.  Figure  21  shows  these  different  formats  with  one  or 

more  of  the  optional  line  breaks  taken. 
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ALL(item  :  type1  SUCH  THAT  foo(a)  <  27  ::  item  =  'item  +  1) 

ALL(item :  type1 

SUCH  THAT  foo(a)  <  27  ::  item  =  *item  +  1 ) 

ALL(item  :  type1  SUCH  THAT  foo(a)  <  27 
::  item  =  *item  + 1) 

ALL(item :  type1 
SUCH  THAT  foo(a)  <  27 
::  rtem  =  *item  +  1) 


Figure  21 
Effect  of  optional  line  breaks  on  display 


D.  DESIGN  DECISIONS 

1.  Spec  Subset 

The  subset  of  Spec  I  chose  to  implement  is  the  Definition  Module.  Definition 
modules  are  used  in  the  requirements  analysis  phase  of  the  software  development  cycle 
[Ref.  1].  Implementing  an  editor  for  the  defmition  module  provides  the  initial  support  for 

utilizing  Spec  in  this  phase  of  software  engineering. 

2.  Type  Checking 

Editors  created  by  the  Synthesizer  Generator  can  have  the  capability  to  perform 
type  checking  provided  the  proper  attribute  equations  are  written  to  support  this 
checking.  However,  since  other  research  is  currentiy  being  done  to  implement  a  separate 
type  checker  for  Spec  [Ref.  15],  the  decision  was  made  to  not  implement  this  capability 
in  the  syntax  directed  editor.  Eventually,  when  the  editor  and  the  type  checker  are  fully 
implemented,  both  tools  will  be  integrated  into  one  larger  tool  that  will  perform  both 
functions. 
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3.  Display  Representation 

In  order  to  make  the  visual  display  "user  friendly",  many  of  the  constructs  in  Spec 
had  productions  added  whose  purpose  is  to  display  a  placeholder  string.  These 
productions  appear  in  both  the  abstract  syntax  and  the  unparsing  grammar.  The  format  of 
these  placeholder  strings  is  the  phylun:  name  enclosed  in  angle  brackets,  e.g.,  <concGpt> 
or  <actual_parm>. 

Although  not  part  of  the  original  Spec  grammar,  these  productions  are  declared  as 
tiie  completing  term  for  the  respective  phylum.  The  phyla  that  have  this  additional 
production  are  all  non-list  phyla,  therefore  the  completing  term  is  also  the  placeholder 
term  for  the  given  phylum.  This  causes  the  visual  display  to  show  where  a  selection 
should  be  made  at  a  later  time  if  a  template  transformation  is  not  selected. 

Some  constructs  in  Spec  already  have  a  usable  completing  term,  specifically  field, 
type_spec,  and  expression,  which  all  use  the  symbol  ?  to  represent  undefined 
occurrences  of  the  respective  phylum. 

4.  Naming  Conventions 

The  following  conventions  were  selected  for  naming  of  phyla,  operators,  and 
attributes: 

•  Abstract  syntax  phyla  are  all  lower  case  (e.g.,  concept),  and  are  exactiy  the  same 
as  the  original  Spec  grammar. 

•  Operators  on  abstract  syntax  phyla  have  the  first  letter  of  each  "word"  within  the 
operator  name  capitalized  (e.g.,  NotGreaterEqual). 

•  Lexemes  are  fully  capitalized  (e.g.,  IDENTIFIER). 
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•  Lexical  phyla  operators  are  capitalized  with  the  same  conventions  as  abstract 
syntax  phyla  operators.  Additionally,  with  the  exception  of  the  special  lexical 
phylum  WHITESPACE,  each  of  these  operators  ends  in  the  word  Lex  (e.g., 
NgeLex). 

•  Template  transformation  names  are  all  lower  case  (e.g.,  "single"),  or  are  a  symbol 
made  of  one  or  more  non-alphanumeric  characters  (e.g., "+"  ot  "-">="). 

•  Concrete  input  syntax  phyla  have  the  same  name  as  the  corresponding  abstract 
syntax  phyla  (with  only  a  few  exceptions)  with  the  first  letter  of  each  "word" 
within  the  name  capitalized  (e.g.,  FormalName  or  IntegerLit,  corresponding  to 
abstract  syntax  phyla  formal_name  and  integeMit,  respectively). 

•  Attributes  are  all  labelled  as  a  lower  case  t,  since  the  only  attributes  used  in  this 
editor  are  synthesized  text  attributes. 

5.  Implementation 

A  listing  of  the  current  implementation  of  SPECDEF  is  given  in  Appendix  B.  A 
user's  manual  for  the  current  version  of  SPECDEF  appears  as  Appendix  C. 
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V.  CONCLUSIONS 

A.  APPLICABILITY  OF  THE  SYNTAX  DIRECTED  EDITOR  FOR  SPEC 

The  SPECDEF  editor  successfully  demonstrates  the  feasibility  of  designing  a  CASE 
tool  for  the  specification  language  Spec.  The  current  version  of  the  editor  supports  a 
subset  of  Spec  consisting  solely  of  definition  modules  and  prevents  the  user  from  writing 
syntactically  incorrect  specifications.  All  Spec  constructs  that  are  applicable  to  a 
definition  module  are  implemented  in  the  editor.  The  SPECDEF  editor  provides  the 
means  to  quickly  and  correcdy  write  Spec  definition  modules  in  support  of  the 
requirements  analysis  phase  of  the  software  development  cycle. 

The  display  representation  is  designed  in  such  a  way  that  the  editor  can  assist  the 
novice  user  in  learning  the  syntax  of  Spec.  As  with  other  syntax  directed  editors  for 
other  languages,  this  could  be  seen  as  a  hindrance  or  an  annoyance  to  the  more 
experienced  Spec  specification  writer,  since  the  method  of  building  a  parse  tree  of  the 
specification  being  edited  requires  the  user  to  traverse  the  entire  parse  tree  of  the  Spec 
grammar  itself. 

A  significant  foundation  has  been  laid  for  designing  an  editor  that  will  implement  the 
entire  Spec  language.  Approximately  half  of  the  Spec  grammar  rules  have  been 
implemented. 
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B.  USEFULNESS  OF  THE  SYNTHESIZER  GENERATOR 

The  Synthesizer  Generator  proved  to  be  an  extremely  useful,  albeit  sometimes 
difficult,  CASE  tool  to  assist  in  the  design  and  implementation  of  a  syntax  directed 
editor.  The  book  and  reference  manual  for  the  Synthesizer  Generator  [Ref.  10  and  11] 
are  not  always  clear  in  their  explanations  of  the  various  concepts  that  must  be  mastered  to 
write  a  successful  editor  specification. 

I  found  it  very  advantageous  to  refer  to  the  specification  of  the  toy.syn  editor,  one  of 
the  sample  editors  that  comes  with  the  sgen  system.  The  specification  file  toy.ssi  can  be 
found  in  the  /usr/suns2/local/syn/editors/toy  directory  on  the  suns2  system.  There  are 
several  other  sample  editors  in  the  /editors  subdirectory  of /syn  whose  specification  files 
may  provide  insight  to  some  readers. 

The  various  options  available  when  invoking  sgen  make  the  Synthesizer  Generator 
system  very  versatile.  Specifically,  the  -v  option  to  flag  Yacc  to  produce  the  diagnostic 
file  y. output  is  extremely  useful  in  debugging  ambiguities  in  the  input  grammar.  The 
ability  of  sgen  to  create  an  editor  for  different  windowing  systems  using  the  -w  option 
makes  this  system  very  powerful,  since  the  same  input  file(s)  can  be  used  to  create  many 
different  editors  that  target  specific  systems. 

The  Synthesizer  Generator  creates  many  intermediate  files  during  the  process  of 
generating  an  editor.  Unless  you  have  prodigious  amoimts  of  free  memory  available,  I 
highly  recommend  that  the  -I  option  (lower  case  L)  not  be  invoked.  This  option  saves  all 
intermediate  files,  which  can  easily  use  up  several  megabytes  of  memory.  Under  normal 
operation  these  files  are  deleted  once  the  executable  editor  file  is  generated. 
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Learning  the  editor  system  commands  to  navigate  around  the  parse  tree  of  a  specifi- 
cation being  edited  is  rather  difficult.  There  is  quite  a  list  of  commands  available;  a 
complete  list  appears  as  Appendix  D.  However,  only  a  portion  of  the  commands  are 
routinely  used  to  edit  a  specification,  as  listed  in  Table  2.  The  use  of  these  commands  is 
discussed  in  the  user's  manual,  which  appears  as  Appendix  C.  Once  these  commands  are 
learned,  writing  a  Spec  definition  module  is  quick  and  easy. 


Table  2:  COMMONLY  USED  EDITOR  COMMANDS 

Command 

Kev-binding 

backward-preorder 

<'^P> 

beginning-of-line 

<'^A> 

delete-next-character 

<'^D> 

delete-other-windows 

<'^X1  > 

delete-previous-character 

<DEL> 

delete-selection 

<'^K> 

end-of-file 

<  ESC->  > 

end-of-line 

<^E> 

enlarge-help 

<  ESC-'^Xz  > 

erase-to-beginning-of-Iine 

<  ESC-DEL  > 

erase-to-end-of-line 

<  ESC-d  > 

execute-command 

<^lorTAB> 

exit 

<'^C> 

forward-preorder 

<^N> 

forward-with-optionals 

<'^M  or  RETURN  > 

left 

<'^B> 

next-window 

<^Xn> 

previous- window 

<'^Xp> 

read-file 

<  '^X'^R  > 

red  raw-display 

<'^L> 

right 

<^F> 

select 

<  ESC-<3)  > 

start-command 

<  ESC-S  > 

write-named-file 

<  '^X'^W  > 
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C.  DEFICIENCIES  AND  BUGS  ENCOUNTERED 

The  SPECDEF  editor  is  strictly  a  syntax  directed  editor.  There  is  no  capability 
provided  for  semantic  checking.  As  stated  previously,  the  type  checking  features  that 
sgen  is  capable  of  producing  are  not  included  in  this  editor  since  independent  research  in 
this  area  is  currendy  in  progress.  This  means  that,  although  a  specification  written  using 
the  editor  will  be  syntactically  correct,  it  is  possible  for  it  to  be  incorrect  semantically. 

One  deficiency  with  the  SPECDEF  editor  is  the  lack  of  support  to  insert  comments 
into  the  specification  being  edited.  Although  sgen  is  capable  of  supporting  this  feature 
when  properly  specified  in  the  editor  specification,  time  constraints  prevented  the 
inclusion  of  this  capability,  which  requires  extensive  coding  to  accomplish. 

D.  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 

1.  Implement  the  Complete  Spec  Language 

The  remainder  of  the  Spec  language  needs  to  be  implemented  in  the  editor.  When 
this  is  accomplished,  the  editor  will  support  not  only  the  requirements  analysis  phase  of 
the  software  development  cycle,  but  also  the  functional  specification  and  architectural 
design  phases. 

2.  Integrate  the  Type  Checker  and  the  Editor 

The  type  checker  currently  being  implemented  independendy  should  be 
integrated  with  the  editor  once  both  tools  are  completed.  This  will  make  the  editor  a  very 
powerful  tool  for  software  engineering  with  Spec.  The  combined  tool  will  form  the 
foundation  of  an  integrated  Spec  programming  environment 
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3.  Integrated  Spec  Programming  Environment 

Many  different  tools  for  Spec  arc  under  development  or  planned  for  futurc 
research.  A  pretty  printer  has  already  been  designed.  The  type  checker  is  currently 
under  development.  Future  research  projects  include  a  consistency  checker,  an 
inheritance  expander,  a  test  oracle,  and  a  diagram  generator.  There  are  also  plans  to 
design  a  translator  from  Spec  specifications  to  con^ilable  Ada  code. 

Each  of  the  above  mentioned  tools,  along  with  the  editor,  are  planned  for 
integration  into  a  programming  environment  for  Spec.  This  environment  will  be  capable 
of  supporting  the  entire  software  development  cycle. 

4.  Investigate  Applicability  of  Utilizing  the  G  ANDALF  System 

The  GANDALF  System  [Ref  7]  might  be  more  useful  than  the  Synthesizer 
Generator  for  creating  a  syntax  directed  editor.  Some  of  the  additional  capabilities  of 
GANDALF  are  the  ability  to  generate  system  environments  that  could  support  multiple 
programmers  on  large  projects,  and  a  limited  project  management  system.  The  need  for 
these  capabilities  should  be  investigated,  and  if  it  is  determined  that  such  a  need  exists, 
future  versions  of  the  editor  should  be  built  using  GANDALF  instead  of  the  Synthesizer 
Generator. 

5.  Automating  the  Design  of  an  SSL  Specification 

After  the  conceptual  breakthrough  occurs  on  how  to  design  an  editor  specification 
using  SSL,  adding  more  constructs  to  the  grammar  becomes  a  relatively  mechanical 
process.  The  different  sections  of  the  SSL  specification  are  closely  related  in  terms  of 
names  of  phyla  and  operators.  This  indicates  a  possibility  that  some  aspects  of  designing 
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an  SSL  editor  specification  could  be  automated.  For  example,  when  an  abstract  syntax 
rule  is  entered,  the  automation  process  could  generate  the  display  representation  rules, 
template  transformation  rules,  etc.,  possibly  through  the  use  of  pop-up  windows  that 
request  specific  information  for  naming  or  formatting  the  additional  rules,  or  asking  for 
information  about  attributes. 

Automating  some  portions  of  this  process  would  enhance  the  usability  of  a  tool 
such  as  the  Synthesizer  Generator.  Additionally,  the  amount  of  time  to  produce  an  editor 
specification  would  be  reduced  dramatically. 
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APPENDIX  A 
COMPLETE  SPEC  GRAMMAR 

The  following  is  a  listing  of  the  complete  grammar  for  the  Spec  specification 
language.  The  current  version  of  Spec  is  1.11.  Optimization  of  the  language  is  still 
under  research,  so  the  reader  can  expect  further  revisions  to  Spec  in  the  future. 

!  version  stamp  SHeader:  speck, v  1.11  89/04/05  14:02:21  berzins  Locked  S 

In  the  grammar,  comments  go  from  a  "!"  to  the  end  of  the  line. 
Terminal  symbols  are  entirely  upper  case  or  enclosed  in  single  quotes  (') . 
Nonterminal  symbols  are  entirely  lower  case. 

Lexical  character  classes  start  with  a  captial  letter  and  are  enclosed  in  {). 
In  a  regular  expression,  x+  means  one  or  more  x's. 
In  a  regular  expression,  x*  means  zero  or  more  x's. 
In  a  regular  expression,  [xyz]  means  x  or  y  or  z. 

In  a  regular  expression,  [*xyz]  means  any  character  except  x  or  y  or  z. 
In  a  regular  expression,  [a-z]  means  any  character  between  a  and  z. 
'.    In  a  regular  expression,  .  means  any  character  except  newline. 

!  definitions  of  lexical  classes 


%def ine 

Digit 

%define 

Int 

%define 

Letter 

%def ine 

Alpha 

%def ine 

Blank 

%define 

Quote 

%def ine 

Backslash 

%define 

Char 

[0-9] 

{Digit )+ 

[a-zA-Z] 

({Letter} I {Digit} !"_") 

[  \t\n] 

["] 

"W" 

([*"\\] I {Backslash} {Quote} I {Backslash) {Backslash}) 


!  definitions  of  white  space  and  comments 


{Blank}+ 
"  —  "  .*"\n' 


!  definitions  of  compound  symbols  and  keywords 


AND 
OR 

NOT 

IMPLIES 

IFF 


'=>" 
•<=>• 
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i 


LE 

GE 

NE 

NLT 

NGT 

NLE 

NGE 

EQV 

NEQV 


,  It  s=n 

•  •*  — <=" 

•  "-*>  =  •• 

•  —  ==•• 


RANGE 
APPEND 
MOD 
EXP 


(Backslash) |MOD 


BIND 
ARROW 


•  n  — >■• 


IF 

THEN 

ELSE 

IN 

U 


:IF 

:THEN 
:ELSE 
:IN 
:U 


ALL 

SOME 

NUMBER 

SUM 

PRODUCT 

SET 

MAXIMUM 

MINIMUM 

UNION 

INTERSECTION 

SUCH 

ELSE  IF 


ALL 

SOME 

NUMBER 

SUM 

PRODUCT 

SET 

MAXIMUM 

MINIMUM 

UNION 

INTERSECTION 

SUCH {Blank }*THAT 

ELSE{Blank)*IF 


AS 

CHOOSE 

CONCEPT 

DEFINITION 

DELAY 

DO 

END 

EXCEPTION 

EXPORT 

FI 

FOREACH 

FROM 

FUNCTION 

GENERATE 

HIDE 

IMPORT 

INHERIT 

INITIALLY 

INSTANCE 

INVARIANT 

MACHINE 

MESSAGE 

MODEL 

OD 


AS 

CHOOSE 

CONCEPT 

DEFINITION 

DELAY 

DO 

END 

EXCEPTION 

EXPORT 

FI 

FOREACH 

FROM 

FUNCTION 

GENERATE 

HIDE 

IMPORT 

INHERIT 

INITIALLY 

INSTANCE 

INVARIANT 

MACHINE 

MESSAGE 

MODEL 

OD 
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OF 

OPERATOR 

OTHERWISE 

PERIOD 

RENANE 

REPLY 

SEND 

STATE 

TEMPORAL 

TIME 

TO 

TRANSACTION 

TRANSITION 

TYPE 

VALUE 

VIRTUAL 

WHEN 

WHERE 


:0F 

: OPERATOR 

:OTHERWISE 

:PERIOD 

rRENAME 

.•REPLY 

:SEND 

: STATE 

: TEMPORAL 

:TIME 

:T0 

: TRANSACT ION 

rTRANSITION 

:TYPE 

: VALUE 

rVIRTUAL 

:WHEN 

: WHERE 


INTEGER_LITERAL 

REAL_LITERAL 

CHAR_LITERAL 

STRING_LITERAL 

NAME 


:(lnt) 
:ilnt)".-{lnt} 

.  n  /  n   n  «  n 

: (Quote) {Char }* {Quote ) 
: {Letter! {Alpha}* 


!  operator  precedences 

!  %left  means  2+3+4  is  (2+3)+4. 

%left  ';',  IF,  DO,  EXCEPTION,  NAME,  SEMI; 

%left  ',',  COMMA; 

%left  SUCH; 

%left  IFF; 

%left  IMPLIES; 

%left  OR; 

%left  AND; 

%left  NOT; 

%left  '<',  '>',  '=',  LE,  GE,  NE,  NLT,  NGT,  NLE,  NGE,  EQV,  NEQV; 

%nonassoc  IN,  RANGE; 

%left  U,  APPEND; 

%left  '+',  '-',  PLUS,  MINUS; 

%left  '*',  '/',  MUL,  DIV,  MOD; 

%left  UMINUS; 

%left  EXP; 

%left  '$',  '[',  '(',  '{',  '.',  DOT,  WHERE; 

%left  STAR; 

%% 

lattribute  declarations 

%% 

!  productions  of  the  grammar 

start 

:  spec 
{  \ 
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spec 


module 


funct  ion 


machine 


type 


def init  ion 


instance 


spec  module 
{  ) 

{  ) 

!  A  production  with  nothing  after  the  "|"  means  the  empty  string 
!  is  a  legal  replacement  for  the  left  hand  side. 


:  function 

{  ) 
I  machine 

(  } 
I  type 

{  ) 
I  definition 

{  ) 
I  instance   !  of  a  generic  module 

{  } 


opt ionally_virtual  FUNCTION  interface  messages  concepts  END 
I  } 

!  Virtual  modules  are  for  inheritance  only,  never  used  directly. 


:  opt ionally_virtual  MACHINE  interface  state  messages  transactions 
temporals  concepts  END 
{     ) 


:  opt ionally_virtual  TYPE  interface  model  messages  transactions 
temporals  concepts  END 
{  ) 


:  DEFINITION  interface  concepts  END 
{     ) 


:    INSTANCE  formal_name  '='  actual_name  END 

{  ) 
I  INSTANCE  foreach  actual_name  END 

{  1 

!  For  making  instances  or  partial  instantiations  of  generic  modules. 
!  The  foreach  clause  allows  defining  sets  of  instances. 
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interface 


formal_name  inherits  imports  export 
{  } 


This  part  describes  the  static  aspects  of  a  module's  interface. 

The  dynamic  aspects  of  the  interface  are  described  in  the  messages. 

A  module  is  generic  iff  it  has  parameters. 

The  parameters  can  be  constrained  by  a  tfHERE  clause. 

A  module  can  inherit  the  behavior  of  other  modules. 

A  module  can  in^ort  concepts  from  other  modules. 

A  module  can  export  concepts  for  use  by  other  modules. 


inherits 


inherits    INHERIT   actual_naii>e   hide    renames 
{     ) 


{     ) 


Ancestors  are  generalizations  or  simplified  views  of  a  module. 
A  module  inherits  all  of  the  behavior  of  its  ancestors. 
Hiding  a  message  or  concept  means  it  will  not  be  inherited. 
Inherited  components  can  be  renamed  to  avoid  naming  conflicts. 


hide 


HIDE  name_list 
{  } 

{     ) 


Useful  for  providing  limited  views  of  an  actor. 

Different  user  classes  may  see  different  views  of  a  system. 

Messages  and  concepts  can  be  hidden. 


renames 


renames  RENAME  NAME  AS  NAME 
{  } 

{  } 


Renaming  is  useful  for  preventing  name  conflicts  when  inheriting 
from  multiple  sources,  and  for  adapting  modules  for  new  uses. 
The  parameters,  model  and  state  components,  messages,  exceptions, 
and  concepts  of  an  actor  can  be  renamed. 


imports 


export 


:  imports  IMPORT  name_list  FROM  actual_name 

I  ) 
I 

{  )  -  - 


EXPORT    name_list 
{     } 

{     ) 
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messages 


message 


response 


messages  message 
{  ) 

(  } 


MESSAGE  formal_message  operator  response 

{     ) 


response_body 
{  ) 
response_cases 


response_cases 

:  WHEN  expression_list  response_body  response_cases 

{  ) 

I  OTHERWISE  response_body 

(  ) 


response_body 

:  choose  reply  sends  transition 
{  } 


choose 


reply 


:  CHOOSE  '  ('  field_list  restriction  ')' 

{  ) 
I 

{     ) 


:  REPLY  actual_message  where 

f  ) 
I  GENERATE  actual_message  where        !  used  in  generators 

{  ) 


sends 


{  1 


:  sends  send 

{     } 
I 

{  ) 


send 


:  opt ional_f oreach  SEND  actual_message  TO  actual_name  where 
{  ) 
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transition 

:  TRANSITION  expression_list         !  for  describing  state  changes 

<  ) 
I 
(  } 


£onnal_message 

:    optional_except ion   opt ional_f ormal_name    f onnal_arguinents 
{     ) 


act ual_mes sage 

:    opt  ional_exception   opt  ional_actual_naine    f  ormal_arguinents 
(     ) 


where 

:  WHERE  expression_list 

{  } 
I  %prec  SEMI   !  must  have  a  lower  precedence  than  WHERE 

{  ) 


opt  ionally_virtual 

:  VIRTUAL 

{  1 
I 

{  ) 


opt ional_except  ion 

:  EXCEPTION 

{  } 
I  %prec  SEMI 

{  ) 


operator 

:  OPERATOR  operator_list 

(  ) 
I 

{  ) 


opt  ional_f oreach 

:  foreach 

{  ) 
I 

{  ) 


foreach 


:  FOREACH  '('  field_list  restriction  ')' 
(  ) 

!  foreach  is  used  to  describe  a  set  of  messages  or  instances 
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concepts 


concept 


:  concepts  concept 

{  } 
I 

{    ) 


:    CONCEPT  formal_nam€  ':'  type_spec  where 

!  constants 

{  ) 
I  CONCEPT  formal_name  formal_arguinents  where  VALUE  formal_arguments  where 

!  functions,  defined  with  preconditions  and  postconditions 

{  ) 


model  !  data  types  have  conceptual  models  for  values 

:  MODEL  forma l_arguments  invariant 
{     ) 


state  !  machines  have  conceptual  models  for  states 

:  STATE  f ormal_arguments  invariant  initially 
(  ) 


invariant     !  invariants  are  true  for  all  states  or  instances 
:  INVARIANT  expression_list 
{  } 


initially     !  initial  conditions  are  true  only  at  the  beginning 
:  INITIALLY  expression_list 
{  } 


transactions 

:  transactions  transaction 

{  ) 
I 

{  } 


transaction 

:  TRANSACTION  f orrr,al_name  '='  action_list  where 
{  } 

!  Transactions  are  atomic. 

!  The  where  clause  can  specify  timing  constraints. 

action_list 

:  action_list  ';'  action     %prec  SEMI     !  sequence 

{     ) 
I  action 

{  } 
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:  action  action     %prec  STAR     !  unordered  set  of  actions 

{  ) 
I  IF  alternatives  FI  !  choice 

{  } 
I  DO  alternatives  OD  !  repeated  choice 

{  ) 
I  actual_name  !  a  normal  message  or  aubtransaction 

(  ) 
I  EXCEPTION  actual_name  !  an  exception  message 

(  } 


alternatives 

:  alternatives  OR  guard  action_list 

{  } 
I  guard  action_list 

{  } 


guard 


temporals 


temporal 


:  WHEN  expression  ARROW 
{  ) 

I 

{  ) 


:  temporals  temporal 

{  ) 
I 

{  ) 


TEMPORAL  NAME  where  response 
i  1 

!  Temporal  events  are  trigged  at  absolute  times, 

!  in  terms  of  the  local  clock  of  the  actor. 

!  The  "where"  describes  the  triggering  conditions 

!  in  terms  cf  TIME,  PERIOD,  and  DELAY. 


opt  ional_f ormal_name 

:  formal_name 

(  } 
I 
{  ) 


formal  name 


:  NAME  f ormal_parameters 
{     ) 


f ormal_parameters         !  parameter  values  are  determined  at  specification  time 
:  '{'  field_list  ')'  where 

{  } 
I 
{  } 
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formal  arguments  !  arguments  are  evaluated  at  run-time 

:  ' ('  field_list  ')' 

{  ) 
I 
{  } 


field  list 


field 


:  field_list  ','  field 

{  } 
I  field 

{    ) 


:  name_list  ':'  typ€_spec 

{  ) 
I  '$'  NAME  ':'  type_spec 

{  ) 
I  '?' 

{  ) 


type_spec 


:  actual_name 

(  ) 
I  '  ?' 

{  ) 


!  name  of  a  data  type 


name  list 


name_list  NAME 
{     ) 
NAME 
{  ) 


optional_actual_name 

:  actual_name 
{  } 


actual  name 


{  } 


NAME  actual_parameters 
{  ) 


actual_parameters         !  parameter  values  are  determined  at  specification  time 
:  ' {'  arg_list  ' }' 


{     ] 
{     ) 


%prec  SEMI   !  must  have  a  lower  precedence  than  '{' 
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actual  arguments  !  arguments  are  evaluated  at  run-time 

:  '  ('  arg_list  ' )  ' 


{     ) 
{     } 


Iprec  SEMI   !  must  have  a  lower  precedence  than  ' (' 


arg_list 


:  arg_list  ' , '  arg 

{  ) 
I  arg 

{  ) 


%prec  COMMA 


arg 


:  expression 

(  ) 
I  pair 

{  } 


expression  list 


expression_list  ','  expression     %prec  COMMA 
(  ) 

expression  %prec  COMMA 

(  } 


expression 


:  quantifier  ' ('  field_list  restriction  BIND  expression  ') 

{  } 
I  actual_name  actual_arguments 

{  ) 
I  actual_name  '@'  actual_name  actual_arguments 

(  } 
1  NOT  expression 


i  expression  AND  expression 

i  } 
I  expression  OR  expression 

I  } 
!  expression  IMPLIES  expression 

{  } 

expression  IFF  expression 

{  } 

expression  '<'  expression 

{  } 

expression  ' >'    expression 

f  } 

expression  '='  expression 

{  ) 

expression  LE  expression 

{    ) 

expression  GE  expression 

{  } 

expression  NE  expression 

{  ) 

expression  NLT  expression 

{  } 

expression  NGT  expression 

{  ) 


%prec  NOT 
%prec  AND 
%prec  OR 
%prec  IMPLIES 
%prec  IFF 
%prec  LE 
%prec  LE 
%prec  LE 
%prec  LE 
%prec  LE 
%prec  LE 
%prec  LE 
%prec  LE 
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expression  NLE  expression 

{  } 

expression  NGE  expression 

{  ) 

expression  EQV  expression 

{  ) 

expression  NEQV  expression 

{  ) 

'-'  expression 

{    ] 

expression  '+'  expression 

{  } 

expression  '-'  expression 

{  ) 

expression  '*'  expression 

(  } 

expression  '/'  expression 

{    ) 

expression  MOD  expression 

{  } 

expression  EXP  expression 

{  ) 

expression  U  expression 

{  } 

expression  APPEND  expression 

{  ) 

expression  IN  expression 

{     ) 

' *'    expression 


%prec  LE 
%prec  LE 
%prec  LE 
%prec  LE 
%prec  UMINUS 
%prec  PLUS 
%prec  MINUS 
%prec  MUL 
%prec  DIV 
%prec  MOD 
%prec  EXP 
%prec  U 
%prec  APPEND 
%prec  IN 
%prec  STAR 


!  *x  is  the  value  of  x  in  the  previous  state 

{  } 

'$'  expression  %prec  DOT 

!  Sx  represents  a  collection  of  items  rather  than  just  one 

!  si  =  (x,  Ss2}  means  si  =  union({x),  s2) 

!  si  =  [x,  Ss2]  means  si  =  append([x],  s2) 

{     ) 

expression  RANGE  expression        %prec  RANGE 

!  x  in  [a  . .  b]  iff  x  in  {a  ..  b)  iff  a  <=  x  <=  b 

!  [a  . .  b]  is  sorted  in  increasing  order 

{    ) 

expression  '.'  NAME  %prec  DOT 

{  } 

expression  ' ['  expression  ']'      %prec  DOT 

{  ) 

' ( '  expression  ' ) ' 

{     } 

'   ('  expression  NAME  ')'  !  expression  with  units  of  measurement 

!  standard  time  units:  NANOSEC  MICROSEC  MILLISEC  SECONDS  MINUTES  HOURS 

DAYS  WEEKS 
{  ) 
TIME 
{  ) 

DELAY 
{  } 

PERIOD 
{  ) 

literal 
{  } 

literal  'g'  actual_name 
{  ) 


!  The  current  local  time,  used  in  temporal  events 

!  The  time  between  the  triggering  event  and  the  response 

!  The  time  between  successive  events  of  this  type 


!  literal  with  explicit  type 
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middle  cases 


quantifier 


restriction 


literal 


'?'        !  An  undefined  value  to  be  specified  later 

{  1 

'!'        !  An  undefined  and  illegal  value 

{  } 

IF  expression  THEN  expression  middle_cases  ELSE  expression  FI 

{  } 


middle_cases  ELSE_IF  expression  THEN  expression 
(  ) 

{  ) 


ALL 
(  ) 
SOME 
{  ) 

NUMBER 

(  ) 

SUM 

{  } 

PRODUCT 

{  } 

SET 

{  ) 

MAXIMUM 

{  } 

MINIMUM 

{  } 

UNION 

{  ) 

INTERSECTION 

{  ) 


SUCH  expression 
(  ) 

{  } 


INTEGER_LITERAL 

{  ) 

REAL_LITERAL 

(  ) 

CHAR_LITERAL 

{  } 

STRING_LITERAL 

{     ) 

'  #'  NAME 

{  ) 

' ['  expressions  ']' 

{  ) 

'{'  expressions  '}' 

{  ) 


!  enumeration  type  literal 
!  sequence  literal 
!  set  literal 
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I  '('  expressions  ' ; '  expression  ')' 

{  ) 
I  ' ['  pair_list  ' ] ' 

{  ) 
I  '{'  NAME  BIND  expression  ')' 

{  } 


!  map  literal 
!  tuple  literal 
!  union  literal 


expressions 


!  relation  literals  are  sets  of  tuples 


:  expression_list 
{    ) 


pair_list 


pair 


{  ) 


:  pair_list  ','  pair 

{    } 
I  pair 

{  } 


name_list  BIND  expression 
{  ) 


operator_list 


operator_list  operator_symbol 
(  ) 

operator_symbol 
{  ) 


operator_syrr±)ol 


:  NOT 

/   V 

1  1 

1  AND 

;   1 

{       1 
1   OR 
r   \ 

\      1 

i  IMPLIES 

1  ) 

1  IFF 

f    \ 

{  ) 
1  '<' 

/  \ 

1  '>' 

1  \ 

{     I 
1  '=' 

{  ) 

1  LE 
f  1 

1  GE 

(  t 
1  NE 

{  ) 

1  NLT 
{  ) 
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I  NGT 

{  ) 
I  NLE 

(  ) 
I  NGE 

{  ] 
I  EQV 

{  } 
I  NEQV 

{  ) 
I  '+' 

{  } 
I  '-' 

i  } 
I  "" 

{  ) 
I  '/' 

{  } 
I  MOD 

{  ] 
I  EXP 

(  ) 
I  U 

{  ) 
I  APPEND 

{  ) 
I  IN 

{  ) 
I  RANGE 

{  ) 
I  '  .' 

{  ) 
I  '  [' 

{  ) 
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APPENDIX  B 
L  SPECDEF  SSL  SPECIFICATION  FILES 

The  following  are  the  SSL  specification  files  for  the  current  version  of  the  SPECDEF 
editor.  There  are  five  modules  broken  down  as  follows:  abstract  syntax  and  template 
transformations,  lexemes,  attribute  declarations,  concrete  input  syntax,  and  unparsing 
schemes. 

A.  ABSTRACT  SYNTAX  AND  TEMPLATE  TRANSFORMATION  RULES 

The  file  adsfracf.ss/ contains  the  abstract  syntax  grammar  and  the  template  transfor- 
mation rules  on  that  grammar  for  the  SPECDEF  editor. 


/* 
/* 
/• 
/• 
/• 
/* 


File:   ABSTRACT. SSL 

This  file  contains  the  abstract  syntax  for  the  Definition  Module 
subset  of  the  Spec  specification  language  for  the  SPECDEF  editor. 
It  also  contains  the  template  transformations  on  the  abstract 
syntax  productions. 


/*  abstract  syntax 
root  start; 
start  : 

optional  list  spec; 
spec  : 


module 


interface        : 

optional  inherits; 
inherits        : 


•/ 


Spec (spec) 


ModuleNilO  /•  completing  term  */ 

ModulePair (module  spec)  /*  allows  addition  of 

other  modules  */ 

DefModuleDecl (interface  concepts) 

/*  Note:  Spec  grammar  has  been  modified  for  this 
editor  to  go  directly  to  the  Definition 
Module  declaration  from  Module   */ 

Interf aceDecl (formal_name  inherits  imports  export) 


InheritNll  () 

InheritPrompt ()         /*  placeholder  term  */ 

InheritStmt (inherits  actual  name  hide  renames) 
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optional  hide; 
hide 


optional  renames 
renames 


optional  imports 
imports 


optional  export; 
export 


HideNil 0 
HidePrompt () 
HideList (name  list) 


/*  placeholder  term  */ 


RenameNil () 

RenamePrompt ()  /*  placeholder  term  */ 

RenameStmt (renames  identifier  identifier) 


ImportNil () 

ImportPrompt 0  /*  placeholder  term  */ 

ImportStmt (imports  name_list  actual_name) 


ExportNil 0 
ExportPrompt () 
ExportList (name_list) 


/*  placeholder  term  */ 


optional  where; 
where 


WhereEmpty () 

WherePrompt ()  /*  placeholder  term  */ 

WhereExp (expression_list ) 


optional  list  concepts; 
concepts        : 


ConceptNil () 

ConceptPair (concept  concepts) 


concept 

where) 
formal  name 


ConceptComp ( )  /*  completing  term  */ 

ConceptType (f ormal_name  type_spec  where) 

Concept Value (formal  name  f ormal_arguments  where  f ormal_arguments 


FormName ( identifier  formal  parameters) 


optional  f ormal_parameters; 

f ormal_parameters  :      FormalParmEmpty () 

1        FormalParmPrompt ( )       /*  placeholder  term  */ 
I        FormalParmList ( field  list  where) 


optional  f ormal_arguments; 


f ormal_argument s 


FormalArgEmpty ( ) 
I        FormalArgPrompt 0        /*  placeholder  term  */ 
I        FormalArgList (f ield_list) 


field  list 


FieldListCompO 
SingleField (field) 
MultiField(field  list  field) 


/*  completing  term  */ 


field 


UndefFieldO  /*  completing  term  */ 

FieldNameList (name_list  type_spec) 
FieldCollect ion  (identifier  type_spec) 


type_spec 


UndefTypeO  /*  completing  term  */ 

NamedType (actual_name) 


name  list 


Nameldent (identifier) 
NamePair (name  list  identifier) 


88 


actual_naine 

optional  actual_: 
actual_parameter 


parameters; 

ActParmEmpty () 
ActParmPrompt () 
ListOfArgs (arg_list) 


optional  actual_ 
actual  arguments 


arg_list 


arg 


express ion_li St 


expression 


ActualParmList (identifier  actual  parameters) 


/*  placeholder  term  */ 


rguments; 

:      ActualArgNil 0 

ActualArgPrompt 0       /*  placeholder  term  •/ 

ActualArgList (arg_list) 


ArgListEmpty 0 
SingleArg (arg) 
MultiArg(arg_list  arg) 

ArgComp ( ) 

ArgExp (expression) 

ArgPair (pair) 


/*  completing  term  */ 


/•  completing  term  */ 


/*  completing  term  */ 


EmptyExpList () 

SingleExp (expression) 

MultiExp (expression_list  expression) 

UndefExpO  /*  completing  term  */ 

Quant  if ierExp (quant  if ier  field_list  restriction  expression) 

IdentExp (actual_name  actual_arguments) 

AtExp (actual_name  actual_name  actual_arguments) 

NotExp (expression) 

AndExp (expression  expression) 

OrExp  (expression  expression) 

Impl iesExp (expression  expression) 

If fExp (expression  expression) 

LessThan (expression  expression) 

GreaterThan  (expression  expression) 

Equal (expression  expression) 

LessEqual  (expression  expression) 

GreaterEqual (expression  expression) 

NotEqual  (expression  expression) 

NotLessThan  (expression  expression) 

NotGreaterThan (expression  expression) 

NotLessEqual (expression  expression) 

NotGreaterEqual (expression  expression) 

Equivalent (expression  expression) 

NotEquivalent (expression  expression) 

UnaryMinus (expression) 

Add (expression  expression) 

Subtract (expression  expression) 

Multiply (expression  expression) 

Divide (expression  expression) 

ModExp (expression  expression) 

Exponent (expression  expression) 

UExp (expression  expression) 

AppendExp (expression  expression) 

InExp (expression  expression) 

Star (expression) 

CollectExp (expression) 

RangeExp (expression  expression) 

DotExp (expression  identifier) 

SqBraclcetExp  (expression  expression) 

ParenExp  (expression) 
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optional  middle_cases; 
middle  cases 


qpjantif  ier 


restrict  ion 


literal 


expressions 

pair_list 

pair 

integer_lit 
real_lit 
char  lit 


MeasureExp (expression  identifier) 

TimeExp () 

DelayExpO 

PeriodExp () 

Constant (literal) 

LiteralType ( literal  actual_name) 

IllegalExpO 

If Then  (expression  expression  middle_cases  expression) 


MidCaseNilO 

MiddlePrompt 0  /•  placeholder  term  */ 

MidCase (middle_cases  expression  expression) 


Quant i fierComp ( ) 

Alio 

Some  0 

Number () 

SumO 

Product () 

Set  () 

Maximum () 

Minimum ( ) 

Union  ( ) 

Intersection  ( ) 

Restr ictComp ( ) 
RestrictNil 0 
SuchThat (expression) 


/*  placeholder  term  */ 


EmptyLiteral () 
IntLiteral (integer_lit) 
RealLiteral (real_lit) 
CharLiteral (char_lit) 
StringLiteral (string_lit) 
Enumeration (identifier) 
Sequence (expressions) 
SetLiteral (expressions) 
MapLiteral (expressions  expression) 
TupleLiteral (pair_list) 
OneOfLiteral (pair) 


/*  placeholder  term  */ 


/*  placeholder  term  */ 


ExpressionsComp ( ) 
ExpressionsNil () 
ExpressionsList(expression_list) 


/*  placeholder  term  */ 


PairListComp ( ) 

SinglePair (pair) 

Mult iPair (pair_list  pair) 


PairBind (name_list  expression) 
IntConstant ( INTEGER_LIT) 
RealConstant (REAL_LIT) 
CharConstant (CHAR  LIT) 


/*  placeholder  term  */ 
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string_lit 
identifier 


StringConstant (STRING_LIT) 
Identifier (IDENTIFIER) 


/*  template  commands  */ 

transform  inherits 

on  "empty"      <inherits>: 
on  "addinherit"  <inherits>: 


InheritNilO  , 

InheritStmt  (<inherits>,  <actual_naine>, 
<hide>, <renames>) 


transform  hide 

on  "empty"      <nide>: 
on  "addhide"    <hide>: 


HideNilO, 

HideList (<name  list>) 


transform  renames 

on  "empty"       <renames>; 
on  "addrename"   <renames>: 


RenameNil () , 

RenameStmt  (<renaines>,  <identif  ier>,  <identif  ier>) 


transform  imports 

on  "empty"  <imports>: 

on  "addimport"  <imports>: 

transform  export 

on  "empty"  <export>: 

on  "addexport"  <export>: 


ImportNil ()  , 

ImportStmt (<imports>, <name_list>, <actual_name>) 


ExportNil 0 , 
ExportList (<name  list>) 


transform  where 

on  "empty"       <where>: 
on  "addwhere"    <where>: 


transform  concept 
on  "type" 
on  "value" 


<concept> : 
<concept> : 


WhereEmpty () , 

WhereExp (<expression_list>) 


Concept  Type (<f ormal_name>, <type_spec>, <where> ) , 
Concept Value (<f ormal_name>, <f ormal_arguments>, 

<where>, <formal  arguments>, <where>) 


transform  f ormal_parameters 

on  "empty"       <f ormal_parameters> : 
on  "fieldlist"   <f ormal_parameters> ; 

transform  f ormal_arguinents 

on  "empty"       <f ormal_arguments> : 
on  "fieldlist"   <f ormal_argument s> : 


F  o  rma IP  a  rmEmpt  y  0 , 

Formal? armList (<field  list>, <where>) 


FormalArgEmpty ( ) , 
FormalArgList (<f ield_list>) 


transform  field_list 

on  "single"      <f ield_list> :    SingleField {<f ield>) , 

on  "multiple"    <field  list>:    Mult iField (<f ield  list>, <f ield>) 


transform  field 

on  "namelist"    <field>; 
on  "collection"  <field>; 


transform  type_spec 
on  "named" 


transform  name_list 

on  "single"      <name_list>: 
on  "multiple"    <name  list>: 


FieldNameList (<name_list>, <type_spec>) , 
FieldCollection (<identif ier>, <type_spec>) 


<type_spec>:     NamedType {<actual  name>) 


Nameldent (<identif ier>) , 

NamePair {<name  list>, <ident if ier>) 
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transform  actual_parameters 

on  "empty"       <actual_parameters> ; 
on  "arglist"     <actual_parameters> ; 


ActParmEmpty ( ) , 
ListOfArgs (<arg_list>) 


transform  actual_arguments 

on  "empty"      <actual_arguments> ! 
on  "arglist"     <actual_arguments> : 


ActualArgNil () , 
ActualArgList (<arg  list>) 


transform  arg_list 
on  "single" 
on  "multiple' 


<arg_list>:      SingleArg (<arg>) , 
<arg_list>:     MultiArg (<arg_li»t>,  <arg>) 


transform  arg 

on  "expression"  <arg>: 
on  "bindpair"    <arg>: 


ArgExp(<expression>)  , 

ArgPair (<pair>) 


transform  expression_list 

on  "single"      <expression_list> ; 
on  "multiple"   <expression  list>; 


SingleExp (<expression>)  , 

MultiExp (<expression  list>, <expression>) 


transform  expression 
on  "quantify' 


<expression>  ; 


on 

"actname" 

<expression> 

on 

„g„ 

<expression> 

on 

n,„ 

<expression> 

on 

"S" 

<expression> 

on 

"t" 

<expression> 

on 

"implies" 

<expression> 

on 

"iff" 

<expression> 

on 

"<" 

<expression> 

on 

">" 

<expression> 

on 

"  =  " 

<expression> 

on 

•■<=" 

<expression> 

on 

">=" 

<expression> 

on 

n^  —  n 

<expression> 

on 

"_<>. 

<expression> 

on 

"->" 

<expression> 

on 

"~<  =  " 

<expression> 

on 

••~>=" 

<expression> 

on 

"==" 

<expression> 

on 

"~  =  =  " 

<expression> 

on 

"uminus" 

<expression> 

on 

n  ^  It 

<expression> 

on 

n_n 

<expression> 

on 

n  «n 

<expression> 

on 

It  /n 

<expression> 

on 

"mod" 

<expression> 

on 

n  «  *  n 

<expression> 

on 

"U" 

<expression> 

on 

"append" 

<expression> 

on 

"in_exp" 

<expression> 

on 

"star" 

<expression> 

on 

"collect" 

<expression> 

on 

"range" 

<expression> 

on 

"dot" 

<expression> 

on 

"[]" 

<expression> 

on 

"parens" 

<expression> 

on 

"measure" 

<expression> 

on 

"time" 

<expression> 

Quant  if ierExp (<quantif ier>, <f ield_list>, 

<restrict ion>, <expression>) , 
IdentExp (<actual_name>, <actual_arguments>) , 
At Exp  (<actual_name>, <actual_name>, 

<actual_arguments>) , 
NotExp (<expression>) , 
AndExp (<expression>, <expression>) , 
Or Exp (<expression>, <expression>) , 
ImpliesExp (<expression>, <expression>) , 
If fExp (<expression>, <expression>)  , 
LessThan  {<expression>, <expression>) , 
GreaterThan (<expression>, <expression>) , 
Equal (<expression>, <expression>) , 
LessEqual (<expression>, <expression>) , 
GreaterEqual (<expression>, <expression>) , 
NotEqual (<expression>, <expression>) , 
NotLessThan (<expression>, <expression>) , 
NotGreaterThan (<expression>, <expression>) , 
NotLessEqual (<expre3slon>, <expression>) , 
NotGreaterEqual (<expression>, <expression>) , 
Equivalent (<expression>, <expression>) , 
NotEquivalent (<expression>, <expression>) , 
UnaryMinus (<expression>) , 
Add (<expression>, <expression>) , 
Subtract (<expression>, <expression>) , 
Multiply (<expression>,<expression>). 
Divide (<expression>, <expression>) , 
ModExp (<expre88ion>, <expression>) , 
Exponent (<expression>, <expression>) , 
UExp  (<expre8sion>, <expression>) , 
AppendExp (<expression>, <expression>) , 
InExp (<expression>, <expression>) , 
Star  (<expression>) , 
CollectExp (<expre8sion>) , 
RangeExp  (<expre8sion>, <expression>) , 
DotExp (<expression>, <ident if ier>) , 
SqBracketExp (<expression>, <expression>) , 
ParenExp (<expre8sion>) , 
MeasureExp (<expre8sion>, <ident if ier>) , 
TimeExp () , 
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on  "delay"  <expression> :  DelayExpO, 

on  "period"  <expression> :  PeriodExpO, 

on  "constant"  <expression> :  Constant  (<literal>) , 

on  "lit_type"  <expression> :  LiteralType (<literal>, <actual_name>) , 

on  "illegal"  <expression> :  IllegalExp () , 

on  "if_then"  <expression> :  IfThen (<expression>, <expression>, <middle_cases>, 

<expression>) 


transform  middle_cases 
on  "empty" 
on  "middle" 


<middle_cases>:  MidCaseNil () , 

<middle_cases> :  MidCase (<middle_caaes>, <expression>, <expresslon>) 


transform  quantifier 

on  "all"  <quantifier>! 

on  "some"  <qtuantif  ier>  ; 

on  "number"  <quantif ier> ; 

on  "sum"  <quantif ier> ; 

on  "product"  <quantif ier> ; 

on  "set"  <quantif ier> i 

on  "max"  <cjuantif  ier>  ; 

on  "min"  <quantif ier> ; 

on  "union"  <quantif ier> ; 

on  "intersect"  <quantif ier> ; 


Alio, 
Some  0  , 
Niunber  () , 
Sum ( ) , 
Product {) , 
SetO. 
Maximum ()  , 
Minimum  () , 
Union  ()  , 
Intersection  () 


transform  restriction 
on  "empty" 
on  "suchthat" 


<rest  r  let  ior.>  ; 
<restr ict ion> ; 


RestrictNil () , 
SuchThat (<expression>) 


transform  \ 

Literal 

on 

"int" 

<literal> 

on 

"real_ 

lit" 

<literal> 

on 

"char 

lit" 

<literal> 

on 

"str_lit" 

<literal> 

on 

"enum" 

<literal> 

on 

"seq" 

<literal> 

or 

"set" 

<literal> 

on 

"map" 

<literal> 

on 

"tuple 

" 

<literal> 

on 

"one  0 

f 

<literal> 

IntLiteral (<integer_lit>) , 
RealLiteral (<real_lit>) , 
CharLiteral (<char_lit>) , 
StringLiteral (<string_lit>) , 
Enumeration (<identif ier>) , 
Sequence (<expressions>) , 
SetLiteral (<expressions>) , 
MapLiteral {<expressions>, <expression>) 
TupleLiteral (<pair_list>) , 
OneOfLiteral (<pair>) 


transform  expressions 
on  "empty" 
on  "explist" 


<expressions> :   ExpressionsNi 1  ( ) , 

<expressions> :   ExpressionsList (<expression_list>) 


transform  pair_list 
on  "single" 
on  "multi" 


<pair_list>:     SinglePair (<pair>) , 
<pair_list>:     MultiPair (<pair_list>, <pair>) 
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B.  LEXICAL  PHYLA  DECLARATIONS 

The  file  lexemes.ssl  contains  the  declarations  of  the  lexemes  for  the  SPECDEF 
editor  (i.e.,  the  keywords,  puncutation  marks,  and  other  special  characters. 


*/ 

This  file  contains  the  lexeme  declarations  for  the  SPECDEF  editor   */ 


/«  File:   LEXEMES.SSL 

/• 

/• 


/*  lexemes  */ 
WHITESPACE: 


Whitespace<  [\  \t\n]*  >; 


AND: 

OR: 

NOT: 

IMPLIES: 
IFF: 


AndLex<  "f   >; 
OrLex<  "|"  >; 
NotLex<  "-"  >; 
ImpliesLex<  "=>"  >; 
IffLex<  "<=>"  >; 


GT: 

LT: 

LE: 

GE: 

NE: 

NLT: 

NGT: 

NLE: 

NGE: 

EQV: 

NEQV: 


GtLex<  ">"  >; 
LtLex<  "<"  >; 
LeLex<  "<="  >; 
GeLex<  ">="  >; 
NeLex<  "-="  >; 
NltLex<  "-<"  >; 
NgtLex<  "~>"  >; 
NleLex<  "-<="  >; 
NgeLex<  "~>="  >; 
EqvLex<  "=="  >; 
NeqvLex<  "-=="  >; 


RANGE: 

APPEND: 

MOD: 

EXP: 

BIND: 


RangeLex<  ".."  >; 
AppendLex<  "II"  >; 
ModLex<  "\\"  >; 
ExpLex<  "*«"  >; 
BindLex<  " : :"  >; 


IF: 

THEN: 

ELSE: 

IN: 

U: 


IfLex<  "IF"  >; 

ThenLex<  "THEN"  >; 
ElseLex<  "ELSE"  >; 
InLex<  "IN"  >; 
ULex<  "U"  >; 


ALL:  AllLex<  "ALL"  >; 

SOME:  SomeLex<  "SOME"  >; 

NUMBER:  NumberLex<  "NUMBER"  >; 

SUM:  SumLex<  "SUM"  >; 

PRODUCT:  ProductLex<  "PRODUCT"  >; 

SET:  SetLex<  "SET"  >; 

MAXIMUM:  MaximumLex<  "MAXIMUM"  >; 

MINIMUM:  MinimumLex<  "MINIMUM"  >; 

UNION:  UnionLex<  "UNION"  >; 
INTERSECTION:    IntersectLex<  "INTERSECTION"  >; 

SUCH:  SuchLex<  "SUCH"[\  \t\n]+"THAT"  >; 

ELSE  IF:  ElseIfLex<  "ELSE"[\  \t\n]+"IF"  >; 
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AS:  AsLex<  "AS"  >; 

CONCEPT:  ConceptLex<  "CONCEPT"  >; 

DEFINITION:  DefnLex<  "DEFINITION"  >; 

DELAY:  DelayLex<  "DELAY"  >; 

END:  EndLex<  "END"  >; 

EXPORT:  ExportLex<  "EXPORT"  >; 

FI:  FiLex<  "FI"  >; 

FROM:  Frona.ex<  "FROM"  >; 

HIDE:  HideLex<  "HIDE"  >; 

IMPORT:  ImportLex<  "IMPORT"  >; 

INHERIT:  InheritLex<  "INHERIT"  >; 

PERIOD:  PeriodLex<  "PERIOD"  >; 

RENAME:  RenameLex<  "RENAME"  >; 

TIME:  TimeLex<  "TIME"  >; 

VALUE:  ValueLex<  "VALUE"  >; 

WHERE:  WhereLex<  "WHERE"  >; 


SEMI: 

COMMA: 

PLUS: 

MINUS: 

MUL: 

DIV: 

UMINUS: 

DOT: 

STAR: 


SemiLex<  ";"  >; 
CommaLex<  ","  >; 
PlusLex<  "+"  >; 
MinusLex<  "-"  >; 
MulLex<  "•"  >; 
DivLex<  "/"  >; 
UininusLex<  "-"  >; 
DotLex<  "."  >; 
StarLex<  "•"  >; 


INTEGER_LIT:  IntegerLex<  [0-9]+  >; 

REAL_LIT:  RealLex<  [ 0-9] +" . " [ 0-9] +  >; 

CHAR_LIT:  CharLex<  n'"[^\n]"'"  >; 

STRING_LIT:  StringLex<  [ "] [ ^"\\ ] * [ " ]  >; 

IDENTIFIER:  IdentLex<  [a-zA-Z ] [a-zA-Z  0-9] 


C.  ATTRIBUTE  DECLARATIONS 

The  file  attribs.ssi  contains  the  attribute  declarations  and  replacement  rules  for  the 
concrete  input  syntax  for  textual  input. 


/♦  File: 

/* 

/* 

I* 


ATTRIBS.SSL 

This  file  contains  the  attribute  declarations  for  the  concrete 
input  syntax  for  the  SPECDEF  editor. 


/*  association  between  abstract  syntax  and  concrete  input  syntax  */ 


Module 

Interface 

Inherits 

Hide 

Renames 

Imports 

Export 

Where 

Concepts 

Concept 

FormalName 


syn  module  t; 

syn  interface  t; 

syn  inherits  t  ; 

syn  hide  t; 

syn  renames  t; 

syn  imports  t; 

syn  export  t; 

syn  where  t; 

syn  concepts  t; 

syn  concept  t; 

syn  forma l_name  t; 
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FormalParm 

syn 

FormalArg 

syn 

FieldList 

syn 

Field 

syn 

TypeSpec 

syn 

NameList 

syn 

ActualName 

syn 

ActualParm 

syn 

ActualArgs 

syn 

ArgList 

syn 

Arg 

syn 

ExpList 

syn 

Exp 

syn 

MlddleCases 

syn 

Quantifier 

syn 

Restriction 

syn 

Literal 

syn 

Expressions 

syn 

PairList 

syn 

Pair 

syn 

IntegerLit 

syn 

RealLit 

syn 

CharLit 

syn 

StringLit 

syn 

Ident 

syn 

/*  replacement  r\ 

jles 

module 

forma l_paramete 

f ormal_argument 

fleld_list 

field 

type_spec 

name_list 

actual_name 

actual_paramete 

actua l_argument 

arg_list 

arg 

express ion_list 

expression 

middle_cases 

qfuant  if  ier 

restriction 

literal 

expressions 

pair_list 

pair 

integer_lit 

real_lit 

char_lit 

string_lit 

identifier 


'/ 


interface 

inherits 

hide 

renames 

imports 

export 

where 

concepts 

concept 

forma l_name 

formal_parameters  ~ 

f ormal_argument s  ~ 

field_list 

field 

type_spec 

name_list 

actual_name 

actual_parameters  -- 

actua l_argument s  ~ 

arg_list 

arg 

expression_list  - 

expression 

middle_cases 

quantifier 

restriction 

literal 

expressions 

pair_list 

pair 


Module.t ; 
Interface . t ; 
Inherits .t; 
Hide.t; 
Renames. t; 
Import s.t; 
Export . t ; 
Where. t; 
Concepts . t ; 
Concept . t ; 
Forma iName . t ; 
FormalParm. t ; 
FormalArg . t ; 
FieldList .t; 
Field. t.- 
TypeSpec.t; 
NameList . t  ; 
ActualName . t ; 
ActualParm. t  ; 
ActualArgs . t ; 
ArgList . t ; 
Arg . t ; 
ExpList  .t  ; 
Exp . t ; 

MiddleCases.t; 
Quantifier  .t ; 
Restriction . t ; 
Literal. t; 
Expressions . t ; 
PairList .t; 
Pair .t; 
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integer_lit 

real_lit 

char_lit 

string_lit 

identifier 


IntegerLit .t; 
RealLit.t; 
CharLit .t; 
StringLit .t; 
Ident .t; 


D.  PRECEDENCE  RULES  AND  CONCRETE  INPUT  SYNTAX 

The  file  concrete,  ssl  contadns  the  precedence  and  associativity  rules  for  the  concrete 
input  syntax,  plus  all  the  concrete  parsing  declarations. 


/*  File:   CONCRETE. SSL  */ 

/*  */ 

/*  This  file  contains  the  precedence  and  associativity  declarations     */ 

/*  and  the  concrete  input  syntax  parsing  rules  for  the  SPECDEF  editor.  */ 


/*  precedence  and  associativity  declarations  */ 
left     ';'  IF  IDENTIFIER  SEMI; 

' , '  COMMA; 

SUCH; 

IFF; 

IMPLIES; 

'  I'  OR; 

'S'  AND; 

'-'  NOT; 

'<'  '>'  •='  LE  GE  NE  NLT  NGT  NLE  NGE  EQV  NEQV; 
nonassoc   IN  RANGE; 
left     U  APPEND; 

' +'  '-'  PLUS  MINUS; 

' *'  '/'  MUL  DIV  MOD; 

UMINUS; 

EXP; 

'$'  ' ['  ' ('  ' {'     ' .'    DOT  WHERE; 

STAR; 


left 
left 
left 
left 
left 
left 
left 
left 


left 
left 
left 
left 
left 
left 


/*  concrete  input  syntax  */ 


Module 


Interface 


Inherits 


:=  (DEFINITION  Interface  Concepts  END) 

(Module. t  =  DefModuleDecl (Interface.t.Concepts.t ) ; ) 

: =  (FormalName  Inherits  Imports  Export) 

(Interface. t  =  InterfaceDecl (FormalName . t , Inherits . t , 
Import s.t, Export .t) ; } 

:=  0  (S$.t  =  InheritNilO  ;  } 

(INHERIT  Inherits  ActualName  Hide  Renames) 

( InheritsSl .t  =  InheritStmt (InheritsS2 .t , ActualName . t , 
Hide. t, Renames. t) ; ) 


Hide 


Renames 


0 

(HIDE  NameList) 


{S$.t  =  HideNilO  ;} 

{Hide.t  =  HideList (NameList .t) ; ) 


:=  0   ($S.t  =  RenameNilO;) 

(Renames  RENAME  Ident  AS  Ident) 

(RenamesSl.t  =  RenameStmt (Renames$2 .t, IdentSl .t, Ident S2 .t) ; ) 
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Imports  ::=  0   {$S.t  =  ImportNil () ; } 

I    (Imports  IMPORT  NameList  FROM  ActualName) 

( Import sSl . t  =  Import Stmt ( Import sS2 .t , NameList .t , ActualName . t ) ; ) 

s 
Export  ::=  ()  ($S.t  =  ExportNil ( ) ; } 

I    (EXPORT  NameList)    {Export. t  =  ExportList (NameList .t) ; ) 

Where  ::=  (prec  SEMI)  {$S.t  =  WhereEmpty () ; ) 

I    (WHERE  ExpList)      (Where. t  =  WhereExp (ExpList .t ) ; ) 

Concepts         ::=  (Concept)  (Concepts. t  =  (Concept. t  ::  ConceptNil) ; } 

I    (Concept  Concepts) 

{Concepts$l.t  =  (Concept. t  ::  Concepts$2 .t) ; } 

Concept  ::=  (CONCEPT  FormalName  ':'  TypeSpec  Where) 

{Concept. t  =  ConceptType (FormalName .t, TypeSpec .t , Where .t) ; ) 
I    (CONCEPT  FormalName  FormalArg  Where  VALUE  FormalArg  Where) 

{Concept. t  =  ConceptValue (FormalName. t,FormalArgSl .t.WhereSl .t. 
Forma lArgS2.t,WhereS2.t) ; } 

FormalName       ::=  (Ident  FormalParm) 

(FormalName .t  =  FormName (Ident .t , FormalParm. t ); ) 

FormaiPariT,       ::=  ()  {SS.t  =  FormalParmEmpty  ( )  ;  ) 

I    ('{'  FieldList  '}'  Where) 

{FormalParm. t  =  FormalParmList (FieldList .t, Where . t ); ) 

FormalArg        ::=  {)  {SS.t  =  FormalArgEmpty ( ) ; } 

I    ('  ('  FieldList  ' ) ' ) 

{FormalArg. t  =  FormalArgList (FieldList .t ); } 

FieldList        ::=  (Field)      (FieldList. t  =  SingleField (Field .t) ; } 
I    (FieldList  ','  Field) 

{FieldListSl.t  =  Mult iField {FieldListS2 .t, Field .t ); ) 

Field  ::=  ('?')        {Field. t  =  UndefField  ( ) ; } 

I    (NameList  ' :'  TypeSpec) 

{Field. t  =  FieldNameList (NameList .t, TypeSpec. t) ; ) 
I    CS'  Ident  ':'  TypeSpec) 

(Field. t  =  FieldCollection (Ident .t, TypeSpec. t) ; } 

t 

TypeSpec         ::=  ('?')         { TypeSpec. t  =  Undef Type ( ) ; ) 

I    (ActualName)  (TypeSpec. t  =  NamedType (ActualName .t) ; } 

NameList         ::=  (Ident)      (NameList. t  =  Nameldent (Ident . t ); } 
I    (NameList  ','  Ident) 

(NameListSl .t  =  NamePair (NameList S2 . t , Ident .t) ; } 

ActualName       ::=  (Ident  ActualParm) 

{ActualName .t  =  ActualParmList (Ident .t, ActualParm. t ); } 

ActualParm       ::=  (prec  SEMI)  {SS.t  =  ActParmEmpty () ; ) 

I    ('{'  ArgList  ')')    (ActualParm. t  =  ListOf Args (ArgList . t ) ; ) 

ActualArgs       ::=  (prec  SEMI)  (SS.t  =  ActualArgNil () ; ) 

I    ('('  ArgList  ')')    (ActualArgs .t  =  ActualArgList (ArgList .t) ; } 

ArgList  : :=  (Arg)        {ArgList. t  =  SingleArg (Arg . t ) ; } 

I    (ArgList  ','  Arg  prec  COMMA) 

(ArgListSl.t  =  MultiArg (ArgListS2 .t , Arg.t ) ; } 
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Arg 


(Exp)        {Arg.t  =  ArgExp (Exp. t) ; ) 

(Pair)       (Arg.t  =  ArgPair (Pair . t ) ; } 


ExpList 


Exp 


(Exp  prec  COMMA)     (ExpList. t  =  SingleExp (Exp. t ) ; } 
(ExpList  ' , '  Exp  prec  COMMA) 

(ExpList$l.t  =  MultiExp(ExpList$2.t,Exp.t) ; } 

(•?')        (Exp.t  =  UndefExpO;) 

(Quantifier  '('  FieldList  Restriction  BIND  Exp  ')') 

{Exp$l.t  =  QuantifierExp(Qu*ntifier. t, FieldList -t. 

Restriction. t, ExpS2 .t) ; ) 
(ActualName  ActualArgs)  (Exp.t  ••  IdentExp (ActualNane .t , ActualArgs , 
(ActualName  '0'  ActualName  ActualArgs) 

(Exp.t  =  AtExp{ActualNaineSl  .t,ActualNaineS2.t,  ActualArgs. t)  ;  ) 
('-'  Exp  prec  NOT)         {Exp$l,t  -  NotExp (Exp$2 .t) ; } 
(Exp  '4'  Exp  prec  AND)      {Exp$l.t  -  AndExp (ExpS2 .t , ExpS3 .t) ; ) 
(Exp  'I'  Exp  prec  OR)       (ExpSl.t  -  OrExp (Exp$2 .t,ExpS3 .t) ; } 
(Exp  IMPLIES  Exp  prec  IMPLIES) 

{Exp$l.t  -  ImpliesExp(Exp$2.t,Exp$3.t) ;) 


t);} 


(Exp  IFF  Exp  prec  IFF)  (Exp$l.t 

(Exp  '<'  Exp  prec  LE)  (ExpSl.t 

(Exp  '>'  Exp  prec  LE)  {Exp$l.t 

(Exp  '='  Exp  prec  '=')  (ExpSl.t 

(Exp  LE  Exp  prec  LE)  (ExpSl.t 

(Exp  GE  Exp  prec  LE)  (ExpSl.t 

(Exp  NE  Exp  prec  LE)  (ExpSl.t 

(Exp  NLT  Exp  prec  LE)  (ExpSl.t 


IffExp(ExpS2.t,ExpS3.t) ; ) 
LessThan  (ExpS2 . t , ExpS3 . t ) ; ) 
GreaterThan (ExpS2 .t,Exp$3 .t) ; ) 
Equal (Exp$2.t,Exp$3.t) ; } 
LessEqxial  (ExpS2  .  t ,  Exp$3  .  t )  ;  } 
GreaterEqual (ExpS2 .t,ExpS3 . 
NotEqual (Exp$2 . t , ExpS3 . t ) ; ) 
Not LessThan (Exp$2 . t , ExpS3 . t 


(Exp  NGT  Exp  prec  LE) 

(ExpSl.t  =  NotGreaterThan (ExpS2.t,ExpS3.t) ; } 
(Exp  NLE  Exp  prec  LE)       (ExpSl.t  =  NotLessEqual (ExpS2 . t , ExpS3 . 
(Exp  NGE  Exp  prec  LE) 

(ExpSl.t  =  NotGreaterEqual (ExpS2.t,ExpS3.t) ; ) 


t);} 
);} 

t);} 


(Exp  EQV  Exp  prec  LE) 
(Exp  NEQV  Exp  prec  LE) 
(UMINUS  Exp  prec  UMINUS) 
(Exp  '+'  Exp  prec  PLUS) 
(Exp  '-'  Exp  prec  MINUS) 
(Exp  '*'  Exp  prec  MUL) 
(Exp  ' /'  Exp  prec  DIV) 
(Exp  MOD  Exp  prec  MOD) 
(Exp  EXP  Exp  prec  EXP) 
(Exp  U  Exp  prec  U) 
(Exp  APPEND  Exp  prec  APPEND) 
(Exp  IN  Exp  prec  IN) 
(' *'  Exp  prec  STAR) 
(' S'  Exp  prec  DOT) 
(Exp  RANGE  Exp  prec  RANGE) 
(Exp  '.'  Ident  prec  DOT) 


(Exp  ' ['  Exp  ' 
('  ('  Exp  ') ') 
('  ('  Exp  Ident 
(TIME) 
(DELAY) 
(PERIOD) 
(Literal) 
(Literal 


prec  DOT) 


{SS. 
(SS. 
(SS. 
(Exp.t 


=  Equivalent {ExpS2.t,ExpS3 .t) ; ) 
=  NotEquivalent (ExpS2 . t , ExpS3 . t ) ; ) 
=  UnaryMinus (ExpS2.t) ; } 
=  Add(ExpS2.t,ExpS3.t)  ; ) 
=  Subtract (Exp$2.t,ExpS3.t) ; } 
=  Multiply (ExpS2. t, ExpS3. t)  ;  } 
=  Divide (Exp$2.t,ExpS3.t) ; ) 
=  ModExp(ExpS2.t,ExpS3.t) ; } 
=  Exponent (ExpS2.t,ExpS3.t) ; } 
=  UExp(ExpS2.t,Exp$3.t) ; ) 
(ExpSl.t  -  AppendExp(Exp$2.t,ExpS3.t) ; ) 
(ExpSl.t  =  InExp(ExpS2.t,ExpS3.t) ; ) 
(ExpSl.t  =  ExpS2.t; } 
(ExpSl.t  =  CollectExp(ExpS2.t) ; ) 
(ExpSl.t  =  RangeExp (Exp$2.t,ExpS3 .t) ; } 
(ExpSl.t  -  DotExp(ExpS2.t, Ident .t) ; } 

SqBrac)tetExp(Exp$2.t,ExpS3.t)  ;  } 
ParenExp (ExpS2 . t )  ;  ) 
MeasureExp(ExpS2.t, Ident .t) ; ) 


(ExpSl.t 

(ExpSl.t 

(ExpSl 

(ExpSl 

(ExpSl 

(ExpSl 

(ExpSl 

(ExpSl 

(ExpSl 

(ExpSl 


(ExpSl.t 

(ExpSl.t 
)         (ExpSl.t 
=  TimeExp  () ; ) 
=  DelayExpO  ;  ) 
=  PeriodExpO  ;  ) 

Constant (Literal. t) ; ) 


ActualNaine) 

(Exp.t  =  LiteralType (Literal .t, ActualName .t) ; } 
('  !'  )        (SS.t  =  IllegalExpO  ;) 
(IF  Exp  THEN  Exp  MiddleCases  ELSE  Exp  FI) 

(ExpSl.t  =  IfThen(ExpS2.t,Exp$3.t, MiddleCases. t,ExpS4, 


t);) 
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MiddleCases 


Quantifier 


Restriction 


Literal 


Expressions 

PairList 

Pair 

IntegerLit 

RealLit 

CharLit 

StringLit 

Ident 


0   {$$.t  =  MidCaseNil () ; ) 
(MiddleCases  ELSE_IF  Exp  THEN  Exp) 

(MiddleCasesSl.t  =  MidCase (MiddleCases$2 . t , Exp$l .t , Exp$2 .t ) ; ) 


(ALL) 

(SOME) 

(NUMBER) 

(SUM) 

(PRODUCT) 

(SET) 

(MAXIMUM) 

(MINIMUM) 

(UNION) 


{$$. 


=    Alio;} 
=   Some ( ) ; ) 


{$$.t  =  Number () ; ) 

{$$.t  =  SumO  ;  } 

{$S.t  =  Product  0 ; ) 

{$$.t  =  SetO;) 

(S$.t  =  Maximum  0 ; ) 

{S$.t  =  Minimum  0 ; ) 

{$$.t  =  UnionO;} 


(INTERSECTION)  {$$  .t    =  Intersection (); ) 


0 

(SUCH  Exp) 

(IntegerLit) 

(RealLit) 

(CharLit) 

(StringLit) 

('#'  Ident) 

( '  [ '  Expressions 

( ' { '  Expressions 

(' ( '  Expressions 

(' ['  PairList  ' ] ' 
('  ('  Pair  '  )' ) 

0 

(ExpList) 


{$$.t  =  RestrictNilO  ;} 
(Restriction. t  -  SuchThat (Exp.t) ; ) 


]') 


)   { 
( 


} 


Literal. t  =  IntLiteral (IntegerLit .t) ; } 
Literal. t  =  RealLiteral (RealLit -t) ; } 
Literal. t  ■=  CharLiteral  (CharLit  .t );  } 
Literal. t  =  StringLiteral (StringLit .t ) 
Literal. t  =  Enumeration (Ident .t) ; ) 

(Literal. t  =  Sequence (Expressions . t 
{Literal. t  =  SetLiteral (Expressions 
Exp  ' ) ' ) 

Literal. t  =  MapLiteral (Expressions .t.Exp.t 
Literal. t  =  TupleLiteral  (PairList .t) ; ) 
Literal. t  =  OneOf Literal (Pair .t) ; } 


);) 
.  t )  ;  } 

);} 


(SS.t  =  ExpressionsNil 0  ;  } 

(Expressions .t  =  ExpressionsList (ExpList .t) ; } 


(Pair)  (PairList. t  =  SinglePair  (Pair . t ) ; } 

(PairList  ','  Pair)  (PairListSl . t  =  MultiPair (PairList $2 .t , Pair . t ); } 

(NameList  BIND  Exp)  {Pair.t  =  PairBind (NameList . t , Exp. t ) ; } 

(INTEGER_LIT)  ( IntegerLit . t  =  IntConstant  (INTEGER_LIT) ; ) 

(REAL  LIT)  (RealLit. t  =  RealConstant (REAL  LIT);} 


(CHAR_LIT) 

(STRING_LIT) 

(IDENTIFIER) 


(CharLit. t  =  CharConstant (CHAR_LIT) ; ) 
(StringLit. t  =  StringConstant (STRING_LIT) ; ) 
{ Ident. t  =  Identifier (IDENTIFIER) ; } 
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E.  UNPARSING  SCHEMES 

The  file  unparse.ssl  contains  the  unparsing  declarations  for  the  display  represen- 
tation of  the  constructs  for  the  SPECDEF  editor. 


/*  File:   UNPARSE.SSL  */ 

/*  */ 

/*        This  file  contains  the  unparsing  rules  for  the  SPECDEF  editor.      */ 


/*  Unparsing  Scheme  */ 
start  : 

spec  : 


module 

interface 
inherits 

hide 


imports 


export 


where 


concepts 


concept 


formal  name 


Spec 

ModuleNil 
ModulePair 

DefModuleDecl 


Inter faceDecl 

InheritNil 

InheritPrompt 

InheritStmt 

HideNil 

HidePrompt 

HideList 

RenameNil 

RenamePrompt 

RenameStmt 

ImportNil 

ImportPrompt 

ImportStmt 

ExportNil 

ExportPrompt 

ExportList 

WhereEmpty 

WherePrompt 

WhereExp 

ConceptNil 
ConceptPair 

ConceptComp 
Concept  Type 

ConceptValue 


FormName 


[  e  :  e  ] 

e   :  ] 
e  ::=  * 


[-%n%n"]  e  ] 


"DEFINITION  "  8   §  "%n" 
"END"  ] 

@  "%t"  @   e   e  "%b%n"  ] 


:=  "<inherit>"  ] 

:=  8  "%n""INHERIT  "  8  "%t"  8   8"%b"  ] 


:=  "<hide>"  ] 

:=  "%n""HIDE  "  8  ] 


:=  "<rename>"  ] 

:=  8  "%n""RENAME  "  8  "  AS  " 


"<import>"  ] 

8  "%n""IMPORT  "  8  "  FROM  " 


:=  "<export>"  ] 

:=  "%n""EXPORT  "  8  ] 


:=  "<where>"  ] 

:=  "WHERE  "  8  ] 

:=  ] 


:=  "   <concept>"  ] 

:=  "%t%n""CONCEPT  "  8  "  :  "  8  "%t%n" 

8  "%b%b%n"  ] 
:=  "%t%n""CONCEPT  "8""e""8  "%t%n" 
"VALUE  "  8  "%n"  8  "%b%b%n"  ] 

:=  8  "  "  8  ] 
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forma l_parameters 

I 


FormalParmEmpty  [ 
FormalParmPrompt  [ 
FormalParmList    [ 


:=  "<f ormal_parm>"  ] 
:=  »("  e  ")  "  e    ] 


formal  arguments  : 


field  list 


field 


type_spec 


name  list 


actual  name 


actual  parameters 


actual  arguments  : 


arg_list 


arg 


expression  list 


expression 


Forma lArgEmpty 
Forma lArgPrompt 
FormalArgList 

FieldListComp 

SingleField 

MultiField 

UndefField 
FieldNameList 
FieldCol lection 

UndefType 
NamedType 

Nameldent 
NamePair 

ActualParmList 

ActParmEmpty 
ActParmPrompt 
ListOf Args 

ActualArgNi 1 

ActualArgPrompt 

ActualArgList 

ArgListEmpty 
SingleArg 
Mult  iArg 

ArgComp 

ArgExp 

ArgPair 

EmptyExpList 

SingleExp 

MultiExp 

UndefExp 

Quant  if ierExp 

IdentExp 

AtExp 

NotExp 

AndExp 

OrExp 

ImpliesExp 

IffExp 

LessThan 

GreaterThan 

Equal 

LessEqual 

GreaterEqual 

NotEqual 

NotLessThan 

NotGreaterThan 


"<formal_args>"  ] 
"C  @  -)"  ] 

"<field>"  ] 

e   ] 

e  ".  "  e  ] 

"?"  ] 

"$"  e  "  :  "  e  ] 

:=  ■?"  ] 

:=  e   ] 


:=  §  ] 


',  "  e  ) 


e  ] 


;=  "<actual_parm>"  ] 

,_  I.  ^  B  g  n  I  n  -j 


=  "<actual_arg>"  ] 
=  -c  e  ")"  ] 

=  "<arg>"  ] 

=  e   ] 

=   e   ",  "  @  ] 

=  "<arg>"  ] 


@  ] 


"<expression_list>"  ] 


",   "  e   ] 


"%("  e 

"( 

"  e 

•'%o"    @    "%}%[%o 

§  e  ] 

e   "6"   i 

@ 

] 

--"  §  ] 

-%{-  @ 

[%o 

i  -  e  "%]%)-  ] 

■%{"  e 

[%o 

1  "  e  "%]%}"  ] 

■%{"  e 

(%o 

=>  -  e  -%]%}"  ] 

■%{"  e 

[%o 

<->  -  e  "%]%}" 

-%{-  e 

[%o 

<  -  @  -%:%)-  ] 

"%{"  e 

[%o 

>  -  e  "%]%}-  ] 

"%("  e 

[%o 

=  "  e  "%]%}-  ] 

-%(-  e 

[%o 

<=  ■•  e  -%]%}-  ] 

-%{"  e 

[%o 

>=  -  e  "%]%)"  ] 

"%{"  e 

[%o 

-=  "  e  "%]%)-  ] 

"%i"  § 

[%o 

-<  -  e  -%]%)-  ] 

"%{"  e 

[%0 

->  "  §  "%]%)"  ] 

@  ")%]"  ] 


102 


middle  cases 


quantifier 


restrict  ion 


literal 


NotLessEqual 

NotGreaterEqual 

Eqruivalent 

Not Equivalent 

UnaryMinus 

Add 

Subtract 

Multiply 

Divide 

ModExp 

Exponent 

UExp 

AppendExp 

InExp 

Star 

CollectExp 

RangeExp 

DotExp 

SqBracketExp 

ParenExp 

MeasureExp 

TimeExp 

DelayExp 

PeriodExp 

Constant 

LiteralType 

IllegalExp 

IfThen 


MidCaseNil 

MiddlePrompt 

MidCase 

Quant  if ierComp 

All 

Some 

Number 

Sum 

Product 

Set 

Maximum 

Minimum 

Union 

Intersection 

RestrictComp 

RestrictNil 

SuchThat 

EmptyLiteral 

IntLiteral 

RealLiteral 

CharLiteral 

StringLiteral 

Enumeration 

Sequence 

SetLiteral 


"%{"  e  "%[%o  ~<= 

"%{"  §  "%[%o  ~>= 

"%{"  e  "%[%o  ==  • 

"%{"  e  "%[%o  -== 


"  /  • 

-  w 
■  •*" 

%{"  e 


e  ] 
e  ] 
e  ] 
e  ] 
e  ] 
e  ] 

"%[%0  u  • 
"%[%o    I  I 
■%[%o    IN 


-  "*■  e  ] 

-  "$"  e  ] 

-  e  ".."  e  ] 

-  e  "."  e  ] 

=  e  "["  e  "]" 
=  -("  e  -)-  ] 
=  -("  §  e  ")" 

"TIME"    ] 
"DELAY"    ] 
"PERIOD"    ] 

=  e   ] 


!    "6"    @    ] 
■    ] 

•%{""IF  "  @  "%t%o%b  THEN 
@  "%t%o%b  ELSE  " 


8  "%t%o%b' 
"  FI%)"  } 


:=  "<middle_cases>"  ] 

:=  "%{"  e  "%o  ELSE  IF  "  e  "%o  THEN  "  6  "%}' 

:=  "<quantifier>"  ] 
"ALL"  ] 
"SOME"  ] 
"NUMBER"  ] 
"SUM"  ] 
"PRODUCT"  ] 
"SET"  ] 
"MAXIMUM"  ] 
"MINIMUM"  ] 
"UNION"  ] 
"INTERSECTION"  ] 

=  "<restriction>"  ] 

=  ] 

=  "  SUCH  THAT  "  e  ] 

=  ■<literal>"  ] 

=  e  ] 
=  §  ] 
=  e  ] 
=  e  ] 
="#"§] 
=  -[-  e  "]-  ] 
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expressions 

pair_list 

pair 

integer_lit 

real_lit 

char_lit 

string_lit 

ident  if ier 


MapLiteral 

TupleLiteral 

OneOfLiteral 

Express ion sComp 
Express ionsNil 
Express ion sLi St 

PairListComp 

SinglePair 

MultiPair 

PairBind 

IntConstant 
RealConstant 
CharConstant 
StringConstant 
Ident  i  f ier 


n,ngn.ngn,„j 

"{"  e  ")"  ] 

"<expressions>"  ] 

] 
§  ] 

-<pair_li5t>"  ] 
§  ] 

e  -,  "  e  ] 
e  "  ::  -  e   ] 
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APPENDIX  C 
L  USER*S  MANUAL  FOR  THE  SPECDEF  EDITOR 

The  SPECDEF  editor  is  a  syntax  directed  editor  for  writing  Spec  specification 
language  definition  modules.  A  syntax  directed  editor,  also  known  as  a  language-based 
editor,  is  one  in  which  the  programs  and  systems  are  created  and  modified  according  to 
the  syntactic  structure  of  the  language.  The  programs  are  represented  internally  as 
abstract  syntax  trees,  or  parse  trees,  that  are  built  by  the  editor  through  constructive 
commands  entered  by  the  user. 

The  "programs"  that  are  manipulated  in  the  SPECDEF  editor  are  actually  specifi- 
cations, not  compilable  programs.  However,  the  Spec  language  has  a  very  well-defined 
syntactic  structure,  just  like  most  programming  languages,  so  a  syntax  directed  editor 
works  just  as  well  for  Spec  as  it  does  for  any  structured  programming  language. 

The  SPECDEF  editor  uses  the  principle  of  immediate  computation  to  analyze  the 
syntactic  correctness  of  the  abstract  syntax  tree  as  it  is  being  constructed.  This  means 
that  as  the  user  enters  each  additional  component  to  the  parse  tree,  or  modifies  an  existing 
component,  the  entire  tree  is  re-analyzed  to  sec  if  the  addition  or  modification  maintains 
a  correct  syntactic  structure.  If  it  does  not,  the  user  is  immediately  signalled  that  a  syntax 
error  has  occurred,  which  must  be  corrected  before  the  editor  will  allow  the  user  to  add 
any  more  components.  In  this  way,  the  editor  ensures  that  only  syntactically  correct  (i.e.. 
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enx)r-free)  specifications  are  written.    This  is  the  key  feature  of  any  syntax  directed 
editor. 

This  editor  was  created  using  the  Synthesizer  Generator,  a  CASE  tool  for  generating 
syntax  directed  editors  from  an  editor  specification  file  containing  the  grammar  rules  (the 
abstract  syntax),  the  display  representation  (known  as  the  unparsing  scheme),  and  the 
concrete  input  syntax  rules  of  the  language  for  which  the  editor  is  designed,  in  this  case 
Spec. 

A.  STANDARD  FEATURES 

Each  editor  specification  results  in  an  editor  with  distinct  characteristics  that  are 
language-dependent.  However,  there  is  a  generic  user  interface  common  to  all  editors 
created  by  the  Synthesizer  Generator.  A  few  of  the  interface  features  have  minor 
differences  dependent  on  the  windowing  system  for  which  the  editor  is  targeted.  These 
differences  are  indicated  where  applicable. 

Throughout  this  user's  manual,  editor  system  commands  are  written  in  boldface. 
Many  of  these  commands  have  one  or  more  key-bindings,  which  are  indicated  by  the  text 
between  angle  brackets  (e.g.,  <  '^l  or  ESC-x  >).  These  are  keys  on  the  keyboard  that  will 
invoke  the  commands.  The  symbol  ^  refers  to  the  CTRL  key,  which  must  be  held  down 
while  depressing  the  key  indicated  immediately  following  the  ^  symbol.  For  example, 
'^C  means  "hold  down  the  CTRL  key  and  depress  the  C  key". 

The  display  screen  of  the  editor  will  normally  have  some  portion  of  the  displayed  text 
highlighted  in  reverse-video.  In  the  diagrams  that  follow,  characters  that  would  appear  in 
reverse-video  on  the  actual  display  are  written  in  boldface. 
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1.  Invoking  and  Exiting  the  Editor 

The  editor  is  invoked  by  typing  the  name  SPECDEF  (or  SPECDEF_SUN  for  the 
Sun  workstation  version  of  the  editor)  at  the  operating  system  prompt  with  an  optional 
list  of  arguments  consisting  of  one  or  more  filenames  of  files  to  be  loaded  into  the  editing 
buffers.  Note  that  the  editor  name  must  be;  typed  in  all  capital  letters.  Invoking  the  editor 
with  no  arguments  causes  editing  to  begin  in  the  default  buffer  main  with  no  associated 
file.  [Ref.  11:  p.  90] 

To  terminate  an  editing  session,  leave  the  editor  and  return  to  the  operating 
system,  the  exit  command  <  '^C,  ESC-'^C,  or  '^X'^C  >  is  executed.  [Ref.  1 1:  p.  91] 

2.  Display  Screen 

The  editor's  display  screen  is  divided  into  four  horizontal  stripes,  or  regions, 
labelled  from  top  to  bottom,  the  title  bar,  the  command  line,  the  object  pane,  and  the  help 
pane,  as  shown  in  Figure  22.  The  title  bar  is  always  highlighted  and  contains  the  name  of 
the  current  buffer  displayed  in  the  object  pane.  The  command  line  echos  commands  and 
error  messages.  The  object  pane  displays  all  or  a  fragment  of  the  current  buffer's 
contents.  The  help  pane,  which  takes  up  the  last  few  lines  of  the  display  window,  lists 
the  currently  selected  constituent,  or  node  in  the  parse  tree,  plus  the  currently  enabled 
template  transformations,  if  any.  [Ref.  10:  p.  21;  11:  p.  91] 

It  should  be  noted  that  the  horizontal  lines  separating  the  panes  in  all  the  diagrams 
of  this  user's  manual  are  for  explanation  purposes  only.  They  do  not  appear  on  the  actual 
video  display  terminal.  The  entire  title  bar,  however,  is  always  highlighted. 
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Title  Bar 

Command  Line 


Object  Pane 


Help  Pane 


Figure  22 
Display  screen  regions 


On  the  Sun  workstation  version  of  the  editor,  the  window  will  also  have  two 
scroll  bars  for  use  with  the  mouse:  one  to  the  right  of  the  object  pane  and  one  below  the 
object  pane.  These  scroll  bars  control  which  portion  of  the  buffer  is  visible  in  the  object 
pane.  [Ref.  11:  p.  91] 

3.  Current  Selection  vs.  Locator 

SPECDEF  is  a  screen-oriented  hybrid  structure  editor,  since  it  permits  editing  the 
structure  of  the  displayed  object  through  template  insertions  as  well  as  allowing 
character-  and  line-oriented  operations  on  the  text  A  template  of  a  component  consists 
of  a  pattern  of  keywords  and  placeholders  where  additional  components  can  be  inserted. 
A  Spec  specification  is  created  top  down  by  invoking  template  transformations  that  insert 
new  components  within  the  framework  of  previously  entered  templates.  These  template 
transformations  are  the  constructive  commands  that  actually  build  the  abstract  syntax 
tree.  [Ref.  10:  pp.  21,26] 
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The  current  selection  indicates  the  individual  component  of  the  specification  at 
which  the  editor  is  positioned.  This  is  indicated  on  the  screen  display  by  highlighting  all 
components  contained  within  the  template  of  the  current  selection.  The  help  pane  also 
tells  the  user  which  component  is  currently  selected  by  displaying  the  message 
"Positioned  at  <component>",  where  <component>  is  the  phylum  name  of  the 
current  selection.  (A  phylum  can  be  thought  of  as  a  node  in  the  abstract  syntax  tree.) 
[Ref.  10:  p.  21] 

A  character  selection  is  displayed  during  text  editing,  indicating  the  specific 
character  position  within  the  highlighted  selection  where  the  next  character  can  be 
entered.  On  standard  video  display  terminals,  this  position  is  denoted  by  an  unhigh- 
lighted  character  within  the  highlighted  selection;  on  Sun  workstations,  the  character 
selection  is  indicated  by  an  I-beam  symbol  within  the  highlighted  selection.  [Ref.  10:  pp. 
22,26] 

The  locator  can  be  used  to  change  the  current  selection  and  the  character 
selection.  On  standard  video  display  terminals,  the  locator  is  the  terminal's  cursor, 
generally  denoted  by  a  blinking  underbar  or  a  blinking  solid  box.  The  locator  can  be 
moved  with  the  commands  pointer-up  <  ESC-p  >,  pointer-down  <  ESC-d  >,  pointer- 
left  <  ESC-b  >,  and  pointer-right  <  ESC-f  >.  Even  after  the  locator  is  moved  to  a  new 
component,  the  new  selection  is  not  made  until  the  select  command  <  ESC-@  >  is 
executed. 
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•  CAUTION:  The  locator  does  not  automatically  move  to  the  new  selection  if  the 
user  changes  selection  by  executing  the  forward-with-optionals  command  <  '^M 
or  RETURN  >.  This  can  be  very  confusing  to  the  user,  since  the  cursor  position 
will  not  correspond  to  the  actual  position  in  the  parse  tree  structure  of  the  object 
being  edited. 

On  Sun  workstations,  the  locator  is  denoted  by  an  arrow.    The  locator's  position  is 

changed  by  moving  the  mouse,  and  the  select  command  is  executed  by  clicking  the 

mouse's  selection  button  (the  left  button).  [Ref.  10:  pp.  22,300] 

B.  TEXT  ENTRY 

Selections  are  displayed  according  to  the  unparsing  schemes,  or  display  templates, 
declared  in  the  editor  specification.  Each  production  in  the  grammar  has  its  own 
template.  The  template  for  each  selection  is  either  editable  as  text  or  it  is  immutable. 
Note  that  a  selection  declared  as  immutable  may  have  elements  within  its  template  that 
are  not  immutable.  The  selection  must  be  moved  to  the  editable  part  b>efore  text  entry  is 
permitted.  [Ref.  10:  pp.  22-23] 

If  the  current  selection  is  not  editable  as  text,  any  attempt  to  type  a  character  is 
rejected  by  the  editor,  sounds  a  warning  signal,  and  displays  the  message  "text  entry  not 
permitted  here"  on  the  command  line,  as  shown  in  Figure  23.  The  selection  must  be 
changed  to  an  editable  component  by  either  repositioning  the  locator  and  executing  the 
select  command  <  ESC-@  >,  or  by  executing  one  of  the  other  structural  selection  by 
traversal  commands,  such  as  forward-preorder  <  '^N  >,  backward-preorder  <  '^P  >, 
forward-with-optionals  <  '^M  or  RETURN  >,  forward-sibling  <  ESC-'^N  >,  forward- 
sibling-with-optionals  <  ESC-'^M  >,  etc.  (Sec  Chapter  3  of  [Ref.  11]  for  other 
structural  selection  by  traversal  commands.)  [Ref.  10:  pp.  22-24;  11:  pp.  101-102] 
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Current  buffer :  main 


text  entry  not  permitted  here 


DEFINITION 
END 


Positioned  at  spec 


Figure  23 
Example  of  illegal  attempt  to  enter  text 


When  the  current  selection  is  editable,  the  entered  text  is  captured  into  the  text  buffer, 
which  is  displayed  in  its  proper  position  in  the  object  pane.  During  editing,  the  selection 
does  not  exist  as  structure,  but  instead  exists  as  text.  Operations  within  the  selection  are 
defined  on  individual  characters  rather  than  on  the  structure.  The  text  entry  is  terminated 
by  executing  forward-with-optionals  <  '^M  or  RETURN  >,  at  which  time  syntactic 
correctness  is  checked.  [Ref.  10:  p.  26] 

If  a  syntax  error  is  detected,  a  warning  signal  sounds,  the  message  "syntax  error" 
appears  on  the  command  line,  and  the  character  selection  is  positioned  at  the  last 
character  of  the  leftmost  error  that  was  detected  For  example,  in  Figure  24,  an  attempt 
was  made  to  enter  (p  :  passenger)  as  a  formal  argument  to  concept  waiting,  but  the  left 
and  right  parentheses  were  not  entered,  resulting  in  a  syntax  error.  [Ref.  10:  p.  27] 
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Current  buffer :  main 

syntax  error 

DEFINITION  warting__passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting  p  :  passenger 

END 

Positioned  at  formal_arguments 

empty 

fieldlist 

Figure  24 
Example  of  a  syntax  error 


To  correct  a  syntax  error,  the  user  can  either  delete  the  entire  text  buffer  by  executing 
the  command  delete-selection  <  '^K  >  and  then  entering  the  correct  text,  or  the  text 
buffer  itself  can  be  edited  with  any  of  a  variety  of  commands  described  below.  There 
will  be  one  character  highlighted  within  the  text  buffer.  This  character  selection  can  be 
moved  with  the  commands  right  <  '^F  >,  left  <  '^B  >,  beginning-of-Iine  <  '^A  >,  or  end- 
of-line  <  '^E  >.  Once  the  character  selection  is  at  the  desired  position,  the  user  can  either 
type  additional  characters  to  be  inserted,  or  delete  unwanted  characters.  Deletion 
commands  are  delete-next-character  <  '^D  >  (which  actually  deletes  the  currently 
highlighted  character),  delete-previous-character  <  DEL  >  (which  deletes  the  character 
to  the  left  of  the  cursor),  erase-to-end-of-line  <  ESC-d  >,  or  erase-to- beginning-of-line 
<  ESC-DEL  >.  [Ref.  11:  pp.  103-104,109] 


112 


C.  TEMPLATE  INSERTION 

When  a  new  selection  is  made,  the  help  pane  is  updated  to  indicate  which  component 
is  selected  and  any  template  transformations  that  are  enabled.  The  template  names  listed 
are  actually  commands  used  to  invoke  the  respective  transfonnations.  [Ref.  10:  p.  23] 

Templates  may  be  selected  in  three  ways,  dependent  on  which  type  of  terminal  is 
being  used.  On  standard  video  display  terminals,  the  user  must  escape  to  the  command 
line  by  invoking  the  execute-command  command  <  '^1,  TAB,  or  ESC-x  >,  and  then 
typing  a  sufficient  number  of  characters  of  the  desired  template  name  to  make  the  choice 
unambiguous.  If  the  prefix  is  ambiguous  because  an  insufficient  number  of  characters 
are  typed,  the  message  "<prefix>  is  ambiguous"  appears  on  the  command  line,  where 
<prefix>  is  the  string  that  the  user  entered,  as  shown  in  Figures  25  and  26.  On  Sun 
workstations  or  other  mouse-equipped  workstations,  transformations  can  be  invoked  by 
clicking  on  the  transformation-name  in  the  help  pane,  or  by  choosing  from  a  pop-up 
menu  of  choices  with  the  mouse's  structure-menu  button  (the  right  button).  [Ref.  10:  p. 
23;  11:  p.  147] 

In  the  SPECDEF  editor,  it  is  recommended  to  expand  the  size  of  the  help  pane  by  two 
lines  to  be  able  to  view  all  the  possible  transformations  available  for  the  phylum 
expression.  This  is  accomplished  by  executing  the  enlarge-help  <  ESC-'^Xz  > 
command  twice  (once  for  each  line  of  expansion).  The  default  size  of  the  help  pane  is 
four  lines,  but  phylum  expression  requires  six  lines,  as  shown  in  Figures  25  and  26. 
[Ref.  11:  p.  98] 
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Current  buffer :  main 


COMMAND:  If 


DEFINITION  waiting  passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting  (p  :  passenger) 
VALUE  (b  :  boolean) 
WHERE  ALL(p  :  passenger ,  f :  floor  ?) 
<concept> 
END 


Positioned  at  expression 
I  implies        iff 
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constant  lit_type  Illegal  if_then 


Figure  25 
Ambiguous  template  transformation  selection 


Current  buffer :  main 


it  is  ambiguous 


DEFINITION  wai1ing_passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting  (p  :  passenger) 
VALUE  (b  :  boolean) 
WHERE  ALL{p  :  passenger ,  f  :  floor  ?) 
<concept> 
END 
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Figure  26 
Result  of  ambiguous  transformation  selection 


114 


Some  selections  do  not  have  any  associated  template  transformations.  This  is 
reflected  in  the  help  pane  by  listing  only  the  current  constituent.  If  an  attempt  is  made  to 
initiate  a  template  insertion  when  no  transformations  are  enabled,  or  an  attempt  is  made 
to  select  a  transformation  other  than  those  enabled,  as  in  Figure  27,  the  editor  will  sound 
a  warning  signal,  display  the  message  "<template-name>  is  unknown  cx)mmand", 
where  <template-name>  is  the  character  string  typed  by  the  user,  and  a  help  buffer  will 
be  displayed  listing  all  the  system  commands  and  their  associated  key-bindings  available 
at  that  location,  as  in  Figure  28.  The  help  buffer  can  be  removed  from  the  screen  with  the 
delete-other-window  command  <  ^X1  >.  [Ref.  10:  p.  25] 


Current  buffer :  main 


COMMAND:  forall 


DEFINITION  waiting_passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting  (p  :  passenger ) 
VALUE  (b  :  boolean  ) 

WHERE  <quantifier>(<fieid><restriction>  ::  ?) 
<concept> 
END 


Positioned  at  quantifier  all  some  number      sum  product 

set  max  min  union  intersect 


Figure  27 
Attempt  to  initiate  non-available  transformation 


The  forward-with-optionals  command  <  '^M  or  RETURN  >  advances  the  selection 
forward  to  the  next  component  in  preorder  when  executed  alone,  including  stopping  at 
any  optional  placeholder  inserted  by  the  editor,  such  as  in  a  list.  However,  when  entering 
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text  or  invoking  a  template  transformation,  the  forward-with-optionals  command 
behaves  differently.  When  a  transformation  is  invoked,  the  selection  moves  to  the  first 
placeholder  (excluding  optionals)  in  the  transformed  component.  If  no  such  placeholder 
exists,  then  the  selection  remains  at  the  same  position  where  the  transformation  was 
invoked.  In  such  instances,  it  appears  to  the  user  that  the  forward-with-optionals 
command  must  be  executed  twice  to  advance  to  the  next  selection.  [Ref.  10:  pp.  37-38] 


Current  buffer :  main 

forall  is  unknown  command 

DEFINITION  walting_passenger 

INHERIT  elevator 

INHERIT  passenger 

Positioned  at  quantifier                    all 
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1           product 
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Current  buffer :  Help 

advance-after-transform 
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backward-with-optlonals 

<'^H> 
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Figure  28 
Unknown  Command  message  and  Help  buffer 
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D.  SAVING  AN  EDITING  SESSION 

Edited  objects  are  contained  in  a  named  buffer,  such  as  the  main  buffer.  To  save  the 
object  being  edited,  the  buffer  contents  must  be  written  to  a  file.  The  command  used  to 
write  such  a  file  depends  on  whether  the  object  was  created  directiy  during  the  current 
editing  session,  or  if  it  was  a  previously  existing  file  loaded  into  the  buffer  as  an 
argument  file  when  the  editor  was  invoked,  or  was  loaded  with  the  command  read-file 
file-name  <  '^X'^F  or  '^X^R  >.  [Ref.  11:  95-97] 

There  are  two  file  formats  in  which  an  object  may  be  saved:  text  or  structure.  A  text 
file  contains  the  display  representation  of  the  object  as  it  would  be  viewed  in  the  object 
pane.  A  structure  file  contains  the  internal  representation  of  the  edited  object.  [Ref.  11: 
p.  95] 

An  object  that  was  saved  as  a  structure  file  can  be  read  back  into  the  editor  for  re- 
editing.  The  unparsing  schemes  that  were  in  effect  at  the  time  the  file  was  written  are 
restored,  since  they  are  saved  as  part  of  the  file  in  these  formats.  A  text  file,  however, 
can  only  be  read  into  the  editor  if  it  can  be  reparsed,  because  the  unparsing  schemes  in 
effect  at  the  time  the  file  was  written  are  not  saved  as  part  of  the  file.  If  the  text  file 
contains  syntactic  errors,  the  file  is  read  into  the  text  buffer  and  the  character  selection  is 
positioned  near  the  error.  This  would  occur  in  the  case  where  the  user  saved  a  file 
immediately  after  attempting  a  syntactically  incorrect  text  entry  but  before  correcting  the 
error.  [Ref  11:  p.  96] 

When  a  previously  existing  file  is  read  into  a  buffer,  the  format  of  the  file  becomes 
associated  with  the  buffer  for  subsequent  write-current-file  commands  <  '^Xs  >.   This 


117 


command  writes  the  current  modified  contents  of  the  buffer  back  to  the  same  file  using 
the  same  format  as  when  the  file  was  read  into  the  buffer.  [Ref .  11 :  p.  97] 

If  the  edited  object  was  created  during  the  current  editing  session,  or  if  the  user 
desires  to  save  a  previously  existing  file  in  a  different  format,  execute  the  command 
write-named-ri\e  file-name  format  <  ^X'^W  >.  The  default  format  is  structure.  A  pop- 
up window  appears  at  the  bottom  of  the  display  screen.  This  window  contains  parameta* 
fields  for  the  user  to  enter  the  filename  of  the  file  to  save  the  buffer  contents  into,  and  the 
format  in  which  to  save  it.  When  the  user  wants  to  save  his  work  for  later  re-editing,  the 
structure  format  should  be  selected.  If  the  user  wants  to  print  the  contents  of  the  buffer, 
tlie  file  should  be  saved  as  a  text  file,  which  can  then  be  printed  as  any  regular  text  file. 
An  example  of  this  pop-up  window  is  shown  in  Figures  29  and  30.  Once  the  parameters 
are  selected,  the  command  start-command  <  ESC-S  >  must  be  executed  to  actually 
write  the  contents  to  the  file.  When  the  editor  is  done  writing  the  file,  the  message 
"Wrote  <filename>"  is  displayed  on  the  command  line,  where  <filename>  is  the  name 
of  the  file  being  written,  and  the  parameters  window  disappears.  [Ref  1 1:  pp.  93,97] 
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Current  buffer :  main 


DEFINITION  waiting_passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting  (p  :  passenger ) 
VALUE  (b  :  boolean  ) 
WHERE  ALL(<field><restriction>  ::  ?) 
<concept> 
END 


-Current  Form  :  Write  File  Form- 


IWRITE  FILE:  <flle-name>  FILE  FORMAT:  structure 

I  Positioned  at  _file_name 


Figure  29 
Pop-up  write-named-file  parameter  window 


Current  buffer :  main 


DEFINITION  waltlng_passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting  (p  :  passenger ) 
VALUE  (b  :  boolean  ) 
WHERE  ALL(<field><restriction>  ::  ?) 
<concept> 
END 


—Current  Form  :  Write  File  Form 

(COMMAND:  text 

(WRITE  FILE:  pass_def.spec  FILE  FORMAT:  structure 

(Positioned  at  Jile_type  text  structure 


Figure  30 
Specifying  text  format  for  Write  File  Form 
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E.  EDITOR  SYSTEM  COMMANDS 

Many  of  the  editor  system  commands  are  similar  or  identical  to  EMACS  text  editor 
command  names  and  standard  key-bindings  [Ref.  11:  p.  90].  The  more  commonly  used 
commands  have  been  described  in  the  preceeding  sections  and  are  summarized  below. 
There  are  numerous  other  less  commonly  used  commands.  Appendix  D  contains  a 
complete  list  of  the  available  editor  commands.  For  a  full  description  of  each  command, 
the  reader  is  referred  to  Chapter  3  of  The  Synthesizer  Generator  Reference  Manual  [Ref. 
11]. 

1.  Executing  Commands  and  Transformations 

Every  editor  command  has  a  name  and  zero  or  more  key-bindings.  There  are  four 
ways  to  invoke  a  command.  First,  the  keystrokes  bound  to  the  command  may  be  typed. 
Second,  the  command  may  be  selected  from  a  menu.  Third,  the  command  name  may  be 
typed  on  the  command  line  of  a  window.  And  lastly,  on  mouse-equipped  systems  only,  a 
mouse  click  may  select  an  actuator  bound  to  the  command.  All  keystrokes  other  than  the 
command  key-bindings  or  escaped  text  entered  on  the  command  line  are  interpreted  as 
textual  insertions  into  the  object  being  edited.  [Ref.  11:  p.  91] 

The  following  commands  are  used  to  execute  transformations  or  to  get  out  of  the 
editor: 

•  exit  <  ^C,  ESC-'^C,  '^X^C  >:  Leave  the  editor  and  return  to  the  shell.  If  any 
buffers  have  been  modified  since  their  associated  files  were  last  written  out,  a 
warning  is  issued  in  a  pop-up  window.  To  abort  the  exit,  execute  as  cancel- 
command  <  ESC-c  >.  To  continue  with  the  exit  command,  execute  a  start- 
command  <  ESC-s  >. 
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•  execute-command  name  <  ^\,  ESC-x  >:  Initiates  the  command  mode  and 
redirects  subsequent  characters  to  the  command  line  following  the  prompt 
COMMAND:.  Entry  on  the  command  line  is  terminated  by  the  first  blank, 
carriage  return,  or  other  command  key-binding.  The  command  name  need  not  be 
typed  in  its  entirety;  any  prefix  of  a  command  that  uniquely  identifies  the 
command  is  sufficient  Transformations  take  priority  over  built-in  commands.  If 
the  command  has  no  parameters,  it  is  executed  immediately.  Otherwise,  a  pop- 
up window  for  parameters  appears;  after  the  parameters  have  been  provided,  the 
command  should  be  initiated  by  executing  start-command.  If  a  command 
parameter  is  either  invalid  or  ambiguous,  an  error  message  is  issued.  Note  that 
the  control  character  '^l  is  TAB. 

•  start-command  <  ESC-S  >:  Initiate  execution  of  a  command  with  the 
parameters  contained  in  the  current  pop-up  parameter  form  window.  If  not 
currently  editing  a  parameter  form,  start -command  does  nothing. 

2.  Buffers,  Selections,  and  Files 

Objects  that  are  being  manipulated  in  the  editor  are  contained  in  a  collection  of 
named  buffers.  Each  file  being  edited  is  typically  read  into  a  distinct  buffer.  The  buffer 
is  then  associated  with  the  given  file  until  either  a  different  file  is  read  into  that  buffer,  or 
the  given  buffer  is  written  out  to  a  different  file.  [Ref  1 1:  p.  95] 

Two  file  formats  are  supported:  text  and  structure.  Text  files  contain  the  display 
representation  of  a  term.  Structure  files  contain  an  internal  representation  of  a  term.  A 
term  is  a  derivation  tree  of  the  object  being  manipulated.  [Ref  1 1:  p.  95] 

Terms  written  as  structure  files  can  be  read  back  into  the  editor  with  the  identical 
structure  as  when  the  file  was  saved.  Text  files,  however,  can  only  be  read  back  into  the 
editor  if  the  text  can  be  reparsed  because  the  unparsing  schemes  in  effect  at  the  time  the 
file  was  written  are  not  saved  within  the  file.  [Ref  11:  p.  96] 
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The  following  commands  are  used  to  read  or  write  files: 

•  read-file  file-name  <  '^X'^F,  '^X^R  >:  Reads  the  named  file  into  the  current 
buffer,  deleting  the  previous  contents  of  that  buffer.  The  buffer  becomes 
associated  with  that  file  for  subsequent  write-current-file  commands.  If  the 
current  buffer  is  already  associated  with  a  file  that  has  not  been  written  since  the 
buffer  was  last  updated,  you  must  answer  yes  to  the  question  Overwrite  buffer? 
before  the  read  will  be  executed.  If  the  given  file  is  text,  it  must  be  syntactically 
correct  with  respect  to  the  input  syntax  of  the  given  editor.  If  syntactically 
incorrect,  the  file  is  read  into  the  text  buffer  with  the  cursor  positioned  near  the 
error.  If  the  given  file  is  a  structured  file,  the  term  contained  in  the  file  and  the 
term  currently  contained  in  the  buffer  must  be  in  the  same  phylum. 

•  write-current-file  <  '^Xs  >:  Write  the  value  of  the  buffer  displayed  in  the 
current  window  to  its  associated  file  in  the  current  format  associated  with  the 

buffer. 

•  write-named-file  file-name  format  <  ^X^V^  >:  Write  the  value  of  the  buffer 
displayed  in  the  current  window  to  the  given  file  in  the  given  format  The 
default  format-structure— can  be  changed  by  selecting  the  format  field  of  the 
pop-up  parameter  window  and  invoking  the  text  transformation. 

3.  Creating,  Deleting,  and  Resizing  Windows  and  Panes 

In  editors  generated  for  standard  video  display  terminals,  windows  are  non- 
overlapping,  are  arranged  in  horizontal  stripes  across  the  screen,  and  are  cyclicly  ordered 
from  top  to  bottom  for  the  purpose  of  the  next-window  and  previous-window 
commands.  [Ref.  1 1:  p.  97] 

In  editors  generated  for  workstations  with  high-resolution,  bitmapped  displays 
(e.g..  Sun  workstations),  resizable  and  overlapping  windows  with  scroll  bars  are 
supported.  [Ref.  1 1 :  p.  98] 

The  following  commands  manipulate  the  windows  and  display: 

•  delete-other-windows  <  '^Xl  >:  Delete  all  windows  other  than  the  current  one. 

•  next-window  <  '^Xn  >:    Switch  to  the  next  window  on  the  screen.    (Video 

display  terminals  only.) 
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•  previous-window  <  '^Xp  >:  Switch  to  the  previous  window  on  the  screen. 
(Video  display  terminals  only.) 

•  enlarge-help  <  ESC-'^Xz  >:  Increase  the  size  of  the  help  pane  of  the  current 
window  by  one  line. 

•  redraw-display  <  '^L  >:  Refresh  the  screen  image  to  remove  any  spurious 
characters. 

4.  Changing  the  Structural  Selection  by  Traversal  of  the  Edited  Term 

The  current  selection  can  be  changed  by  moving  through  the  structure  of  the 
abstract-syntax  tree  (e.g.,  in  preorder,  reverse  preorder,  by  moving  to  the  parent,  etc.).  If 
such  a  motion  would  cause  the  selection  to  leave  the  currently  displayed  text  in  the 
window,  the  object  is  scrolled  automatically  to  keep  the  new  selection  within  the 
window.  [Ref.  11:  p.  101] 

Some  commands  cause  the  editor  to  automatically  insert  instances  of  optional 
components  into  the  abstract  syntax  tree  (e.g.,  forward-with-optionals  <  '^M  or 
RETURN  >).  The  placeholder  for  an  optional  element  becomes  the  current  selection.  If 
the  selection  is  advanced  beyond  an  inserted  optional  element,  and  that  optional  element 
is  still  only  a  placeholder,  that  placeholder  is  removed  from  the  abstract  syntax  tree  (and 
consequently  from  the  display).  Other  commands  that  change  the  selection  ignore  any 
optional  components  and  therefore  do  not  insert  an  instance  of  such  elements  in  the 
abstract  syntax  tree.  [Ref.  1 1 :  p.  101] 

The  following  commands  are  used  to  move  the  selection: 

•  forward-preorder  <  '^N  >:  Change  the  selection  to  the  next  resting  place  in  a 
forward  preorder  traversal  of  the  abstract-syntax  tree.  Do  not  stop  at  place- 
holders for  optional  constituents. 
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•  backward-preorder  <  '^P  >:  Change  the  selection  to  the  previous  resting  place 
in  a  forward  preorder  traversal  of  the  abstract- syntax  tree.  Do  not  stop  at 
placeholders  for  optional  constituents. 

•  right  <  '^F  >:  If  there  is  no  text  buffer,  right  is  the  same  as  forward-preorder. 
See  Section  I.E. 5  for  the  meaning  of  right  when  there  is  a  text  buffer. 

•  left  <  '^B  >:  If  there  is  no  text  buffer,  left  is  the  same  as  backward-preorder. 
See  Section  I.E.5  for  the  meaning  of  left  when  there  is  a  text  buffer. 

•  forward-with-optionals  <  ^M  >:  Change  the  selection  to  the  next  resting  place 
in  a  forward  preorder  traversal  of  the  abstract-syntax  tree.  Stop  at  placeholders 
for  optional  constituents.  Note  the  '^M  is  RETURN. 

•  end-of-file  <  ESC->  >:    Change  the  selection  to  the  rightmost  resting  place  in 

the  abstract  syntax  tree. 

5.  Changing  the  Character  Selection  by  Traversal  of  the  Text  Buffer 

The  text  buffer  contains  text  being  entered  or  re-edited.  This  buffer  is  displayed 
in  its  proper  position  within  its  enclosing  structural  context.  One  character  within  the 
text  buffer  is  selected,  shown  by  a  highlight.  This  character  selection  can  be  moved 
within  the  text  buffer  by  normal  horizontal  and  vertical  "cursor-motion"  commands.  If 
the  character  selection  is  moved  beyond  the  boundaries  of  the  text  buffer,  the  contents  of 
the  text  buffer  are  submitted  for  syntactic  analysis  and  translation.  Within  the  text  buffer, 
the  structural-motion  commands  forward-preorder,  backward-preorder,  right,  and 
left,  which  were  previously  defined  for  moving  the  component  selection,  have  been 
overloaded  and  are  also  used  to  move  the  character  selection  down,  up,  right,  and  left, 
respectively.  [Ref.  11:  p.  103] 
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The  following  commands  are  used  to  change  the  character  selection  within  the 

text  buffer: 

•  forward-preorder  <  '^N  >:  Move  the  character  selection  one  position  down.  If 
already  at  the  last  line  of  the  text  buffer,  this  command  is  interpreted  as  forward- 
after-parse. 

•  backward-preorder  <  '^P  >:  Move  the  character  selection  one  position  up.  If 
already  at  the  first  line  of  the  text  buffer,  this  command  is  interpreted  as 
backward-preorder,  as  described  in  Section  I.E.4,  provided  the  text  is 
syntactically  correct. 

•  right  <  '^F  >:  Move  the  character  selection  one  position  to  the  right.  If  already 
at  the  rightmost  character  of  a  line,  the  character  selection  advances  to  the  first 
character  of  the  next  line  of  the  text  buffer.  If  already  at  the  rightmost  character 
of  the  last  line  of  the  text  buffer,  the  command  is  interpreted  as  forward-after- 
parse. 

•  left  <  '^B  >:  Move  the  character  selection  one  position  to  the  left.  If  already  at 
the  leftmost  character  of  a  line,  the  character  selection  advances  to  the  last 
character  of  the  previous  line  of  the  text  buffer.  If  already  at  the  leftmost 
character  of  the  first  line  of  the  text  buffer,  the  command  is  interpreted  as 
backward-preorder. 

•  beginning-of-line  <  '^A  >:  Move  the  character  selection  to  the  beginning  of  the 
line. 

•  end-of-line  <  '^E  >:  Move  the  character  selection  to  the  end  of  the  line. 

•  forward-after-parse  (no  key-binding):  If  textual  entry  is  terminated  by 
forward-preorder,  then  upon  successful  analysis  the  forward-preorder 
command  is  replaced  by  forward-after-parse.  Let  r  be  the  subterm  or  sublist 
that  has  replaced  the  selection  as  a  result  of  textual  input.  If  no  existing  place- 
holder occurs  within  f,  then  forward-after-parse  stops  at  the  first  resting  place 
beyond  /.  Forward-after-parse  never  inserts  optional  placeholders  either  in  t  or 
beyond  r. 

6.  Moving  the  Locator  on  the  Screen 

The  commands  described  in  this  section  apply  only  to  editors  generated  for 
standard  video  display  terminals  (for  editors  generated  for  workstations  equipped  with  a 
mouse,  the  mouse  can  be  used  to  point  anywhere  in  the  object  pane,  and  clicking  the 
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mouse  will  change  the  current  selection).  It  is  important  to  note  that  the  locator  is 
distinct  from  the  selection.  The  locator  identifies  a  point  on  the  screen  and  not  a  point  in 
the  buffer  (i.e.,  the  locator  does  not  necessarily  agree  with  the  selection  in  the  parse  tree). 
[Ref.  ll:p.  105] 

The  following  commands  move  the  locator  (Le.,  the  cursor): 

•  pointer-left  <  ESC-b  >:  Move  the  locator  one  character  to  the  left.  If  already 
in  column  one  of  the  object  pane  and  not  already  at  the  leftmost  scroll  position, 

scroll  the  window. 

•  pointer-right  <  ESC-f  >:  Move  the  locator  one  character  to  the  right.  If 
already  at  the  right  border  of  the  object  pane,  scroll  the  window. 

•  pointer-up  <  ESC-p  >:  Move  the  locator  one  character  up.  If  already  at  the  top 
of  the  object  pane  and  not  already  at  the  uppermost  scroll  position,  scroll  the 
window. 

•  pointer-dov^Ti  <  ESC-d  >:  Move  the  locator  one  character  down.  If  already  at 
the  bottom  of  the  object  pane,  scroll  the  window. 

7.  Structural  Editing 

Structural  modifications  follow  a  cut-and-paste  paradigm,  similar  to  block-edit 
functions  found  in  many  text  editors.  Only  whole,  well-formed  substructures  can  be 
removed  and  inserted.  [Ref  1 1:  p.  108] 

The  following  commands  are  used  to  move,  copy,  or  delete  entire  subtrees  of  the 
overall  abstract  syntax  tree: 

•  cut-to-clipped  <  '^W  >:  Move  the  selection  of  the  current  buffer  to  the  distin- 
guished buffer  CLIPPED.  The  removed  selection  is  replaced  by  a  placeholder, 
which  becomes  the  new  selection.  The  previous  contents  of  CLIPPED  are  lost. 

•  copy-to-clipped  <  ESC-'^W  >:  Copy  the  selection  of  the  current  buffer  to  buffer 
CLIPPED.  The  previous  contents  of  CLIPPED  are  lost. 
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•  paste-from-clipped  <  '^Y  >:  Move  the  contents  of  buffer  CLIPPED  into  the 
buffer  at  the  current  selection,  which  must  be  a  placeholder.  In  CLIPPED,  a 
placeholder  term  replaces  the  previous  contents. 

•  copy-from-clipped  <  ESC-'^Y  >:  Copy  the  contents  of  buffer  CLIPPED  into 
the  buffer  at  the  current  selection,  which  necessarily  must  be  a  placeholder.  The 
contents  of  CLIPPED  are  left  unchanged. 

•  copy-text-from-clipped  <  ESC-'^T  >:  Copy  the  contents  of  buffer  CLIPPED, 
as  text,  into  a  text  buffer  at  the  current  selection  immediately  preceding  the 
character  selection.  The  contents  of  CLIPPED  are  left  unchanged. 

•  delete-selection  <  '^K  >:  Move  the  selection  of  the  current  buffer  to  the 
distinguished  buffer  DELETED.  The  selection  becomes  a  placeholder.  The 
previous  contents  of  DELETED  are  lost. 

8.  Textual  Editing 

Textual  insertion  and  textual  re-editing  are  permitted  for  some  components  of  the 
language,  as  discussed  in  Section  I.E. 5  above. 

If  a  textual  insertion  is  permitted  at  a  placeholder,  you  merely  begin  to  type;  this 
causes  the  text  of  the  placeholder  to  disappear  and  the  keystrokes  are  echoed  in  the  text 
buffer,  which  is  displayed  in  place  on  the  screen. 

If  textual  re-editing  of  an  existing  structure  is  desired  and  is  permitted,  the 
character  selection  is  positioned  at  the  desired  place  in  the  text  buffer  whereupon  the  user 
can  begin  to  either  type  or  erase  characters.  If  the  current  selection  was  established  by 
tree  traversal,  as  described  in  Section  I.E.4  above,  then  the  textual-insertion  point  is  in 
front  of  the  character  at  which  the  locator  pointed  when  the  select-start  was  executed. 
[Ref.  11:  p.  109] 
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The  following  commands  are  used  to  edit  text  within  the  text  buffer: 

•  delete-next-character  <  '^D  >:  Delete  the  current  character  selection.  If  the 
character  selection  is  at  the  end  of  a  line  in  the  text  buffer  (other  than  the  last 
line),  then  the  current  line  and  the  next  line  are  joined  into  one  line. 

•  delete-previous-character  <  DEL  >:  Delete  the  character  to  the  left  of  the 
character  selection.  If  the  character  selection  is  at  the  beginning  of  a  line  in  the 
te:ct  buffer  (other  than  the  first  line),  then  the  current  line  and  the  previous  line 
are  joined  into  one  line. 

•  erase-to-end-of-line  <  ESC-d  >:  Erase  firom  the  character  selection  to  the  end 
of  the  line,  including  the  character  selection. 

•  erase-to-beginning-of-line  <  ESC-DEL  >:  Erase  from  the  beginning  of  the  line 
to  the  character  selection,  not  including  the  character  selection. 

•  delete-selection  <  '^K  >:  Delete  the  entire  line. 


F.  SAMPLE  EDITING  SESSION 

We  present  a  sample  editing  session  using  the  standard  video  display  terminal  version 
of  SPECDEF.  We  will  create  a  small  specification  file,  save  it  for  later  rc-editing,  recall 
the  file  into  the  editor,  modify  it,  and  save  it  for  printout. 

Some  terminology  that  is  used  throughout  the  remainder  of  this  section  needs  to  be 
clarified: 
•    Recall  that  a  phylum  can  be  thought  of  as  a  node  in  the  abstract  syntax  tree. 


• 


A  completing  term  is  the  default  representation  of  a  phylum.  Completing  terms 
can  be  replaced  through  template  transformations,  if  any  are  enabled.  The 
completing  term  for  some  phyla  are  user  prompts,  consisting  of  the  phylum  name 
enclosed  in  angle  brackets,  e.g.,  <formal_parm>.  Other  phyla  have  template 
patterns  with  keywords  for  the  respective  phylum. 

A  placeholder  term  is  also  a  default  representation  of  a  phylum.  For  non- 
optional  phyla,  the  placeholder  term  is  identical  to  the  completing  term.  But  for 
phyla  that  are  declared  as  optional,  the  placeholder  is  usually  a  user  prompt,  as 
described  above,  indicating  where  a  transformation  can  be  inserted  if  desired. 
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In  the  diagrams  that  follow,  recall  that  text  that  would  appear  as  highlighted  text  on 
an  actual  video  display  is  printed  in  boldface. 

We  invoke  the  editor  by  typing  SPECDEF  at  the  Unix  prompt  with  no  arguments,  as 
we  will  be  creating  the  specification  in  this  editing  session.  The  initial  screen  presented 
to  the  user  has  a  blank  object  pane,  as  shown  in  Figure  31.  Note  that  the  help  pane 
indicates  the  selection  is  positioned  at  phylum  Start. 


Current  buffer :  main 


Positioned  at  start 


Figure  3 1 
Initial  Display  Screen 


There  are  no  template  transformations  enabled  for  phylum  start,  so  we  simply 
advance  the  selection  by  executing  forward-with-optionals  <  '^M  or  RETURN  >.  After 
depressing  the  RETURN  key,  we  are  presented  with  the  display  as  shown  in  Figure  32. 
Phylum  spec  is  declared  as  an  optional  list  phylum,  since  we  may  have  zero  or  more 
occurrences  of  this  construct  according  to  the  Spec  grammar.  Therefore,  what  we  see  in 
the  display  is  the  placeholder  term  for  phylum  spec,  which  happens  to  be  the  completing 
term  for  phylum  module,  the  first  argument  for  phylum  spec. 
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Current  buffer :  main 


DEFINITION 
END 


Positioned  at  spec 


Figure  32 
Advancing  the  selection  to  phylum  spec 


As  we  advance  the  selection  by  executing  forward-with-optionals  <  '^M  or 
RETURN  >  repeatedly  to  cycle  through  phyla  module,  interface,  and  formaI_name, 
the  only  changes  that  occur  to  the  display  screen  are  the  name  of  the  current  selection 
listed  in  the  help  pane,  and  the  disappearance  of  the  highlighting  of  the  keywords 
DEFINITION  and  END  as  the  selection  reaches  interface.  The  next  selection  is 
identifier,  at  which  point  we  decide  to  enter  the  name  of  our  module, 
waiting_passenger,  as  shown  in  Figure  33. 


Current  buffer :  main 


DEFINITION  waiting_passenger 
END 


Positioned  at  identifier 


Figure  33 
Entering  text  at  node  identifier 
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The  text  entry  is  terminated  by  entering  a  carriage  return.  This  causes  the  entered  text 
to  be  checked  for  syntactic  correctness;  it  is  accepted  and  inserted  in  the  abstract-syntax 
tree  at  the  node  for  phylum  identifier.  The  selection  is  advanced  to  formal_parameters, 
as  shown  in  Figure  34. 

Here  we  have  the  first  occurrence  of  a  completing  term/placeholder  term/user  prompt, 
the  string  <formal_parm>,  to  prompt  the  user  that  some  acceptable  form  of  formal 
parameters  should  be  entered  here.  We  also  have  two  template  transformations  enabled 
named  empty  and  fieldiist.  In  this  case  we  do  not  want  any  formal  parameters,  so  we 
invoke  the  transformation  empty  by  first  executing  execute-command  <  '^l  or  TAB  >; 
when  we  depress  the  TAB  key,  the  prompt  COMMAND:  appears  on  the  command  line. 
We  only  need  to  enter  enough  letters  of  the  transformation  name  to  make  our  choice 
unambiguous;  in  this  case,  simply  typing  e  is  sufficient  to  differentiate  between  empty 
and  fieldiist.  After  typing  the  e,  the  screen  appears  as  in  Figure  35. 


Current  buffer :  main 


DEFINITION  waiting_passenger<formal_parm> 
END 


Positioned  at  formal_parameters  empty        fieldiist 


Figure  34 
Display  after  parsing  the  module  name 
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Current  buffer :  main 


COMMAND:  e 


DEFINITION  waiting_passenger<formaI_parm> 
END 


Positioned  at  formal_parameters  empty        fleWlist 


Figure  35 
Invoking  template  transformation  empty 


Any  of  the  several  commands  that  move  the  selection  will  terminate  the  template 
command.  We  use  forward-with-optionals  <  '^M  or  RETURN  >.  The  template  for  an 
empty  forma!_parameter  list  is  executed,  which  replaces  the  placeholder  term 
<formal_parm>  with  a  null. 

The  selection  is  advanced,  and  the  optional  phylum  inherits  is  selected.  Since  this 
phylum  is  optional,  the  completing  term  (a  null  statement)  is  replaced  on  the  display  with 
the  placeholder  term,  the  string  <inherit>.  There  are  two  INHERrT  clauses  we  wish  to 
add,  so  we  invoke  execute-command  twice,  each  time  typing  a  for  addinherit  to  display 
the  templates  for  two  INHERIT  clauses,  as  shown  in  Figure  36.  Note  that  the  selection  is 
still  positioned  at  the  <inherit>  prompt  on  the  first  line,  since  the  abstract- syntax  rule  for 
inherits  inserts  an  instance  of  inherits  at  the  beginning  of  each  clause  until  a  null  clause 
is  selected.  To  get  rid  of  this  prompt  and  advance  to  the  first  INHERIT  clause,  we  must 
invoke  the  transformation  empty  on  the  command  line. 
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Current  buffer :  main 


DEFINITION  waiting  passenqer<lnherit> 
INHERIT  <hide><rename> 
INHERIT  <hide><rename> 

END 


Positioned  at  inherits  empty        addinherit 


Figure  36 
After  invoking  transformation  addinherit  twice 


After  invoking  transformation  empty,  the  selection  is  advanced  to  actual_name. 
We  type  in  the  name  elevator,  the  name  of  the  module  we  wish  to  inherit.  Even  though 
we  did  not  include  any  actual  parameters  after  the  actual  name  elevator,  it  is  still 
accepted,  since  actual  parameters  can  be  empty.  Note  that  we  could  have  advanced  the 
selection  one  level  lower,  to  phylum  identifier,  before  entering  the  name  elevator,  but 
then  we  would  also  have  had  to  invoke  the  transformation  for  an  empty  actual  parameter 
list  and  an  empty  actual  argument  list.  By  entering  the  text  at  phylum  actual_name,  we 
have  saved  some  time  and  effort  by  not  having  to  bother  with  the  empty  parameter  and 
argument  constructs.  Our  display  now  appears  as  in  Figure  37. 

We  do  not  wish  to  hide  or  rename  any  concepts  from  the  inherited  module  elevator, 
so  for  each  of  those  selections  in  turn  we  invoke  the  empty  template  transformation  the 
same  way  we  did  before. 
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Current  buffer :  main 


DEFINITION  waiting  passenger 
INHERIT  elevator  <hlde><rename> 
INHERIT  <hide><rename> 

END 


Positioned  at  hide  enpty        addhide 


Figure  37 
After  entering  inherited  module  name  elevator 


Note  that  after  invoking  execute-command  and  entering  an  e  followed  by  a  carriage 
return,  the  help  pane  still  indicates  the  selection  is  positioned  at  hide  (  also  the  same  for 
rename).  This  is  because  the  hide  (rename)  that  was  replaced  by  a  null  statement  was 
the  optional  selection  that  was  inserted  by  the  editor  when  we  executed  forward-with- 
optionals.  When  the  null  statement  fills  that  node,  the  selection  moves  back  up  the 
abstract-syntax  tree  to  the  hide  (rename)  within  the  template  for  inherits.  By  simply 
executing  forward-with-optionals  <  '^M  or  RETURN  >,  the  placeholder  <hide> 
(<rename>)  is  replaced  by  the  completing  term  (a  null  statement)  and  the  selection  is 
advanced. 

The  same  process  is  performed  for  the  second  INHERTr  clause,  with  the  name 
passenger  for  the  inherited  module.  Again,  we  do  not  wish  to  hide  or  rename  any 
concepts  from  the  inherited  module  passenger,  so  we  invoke  the  empty  transformation 
for  each  of  these  constructs. 
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The  selection  is  now  positioned  at  imports,  another  optional  phylum.  The  place- 
holder term  replaces  the  completing  term  on  the  display,  and  our  screen  looks  like  that 
shown  in  Figure  38. 


Current  buffer :  main 


DEFINITION  waiting_passenger 
INHERIT  elevator 
INHERIT  passenger 
<lmport> 

END 


Positioned  at  Imports  empty         addimport 


Figure  38 
Selection  positioned  at  phylum  imports 


We  do  not  have  any  concepts  we  wish  to  import,  so  we  invoke  the  empty  trans- 
formation. As  we  saw  with  phyla  hide  and  rename,  we  must  execute  forward-with- 
optionals  after  completing  the  transformation  to  advance  the  selection  to  export.  We 
will  not  expon  any  concepts,  so  the  identical  process  is  performed  for  export  as  we  did 
for  imports. 

The  selection  is  now  positioned  at  concepts,  which  is  declared  as  an  optional  list 
phylum.  The  completing  term  for  the  first  argument  of  concepts  is  displayed,  which  is 
the  prompt  <concept>  from  phylum  concept,  as  shown  in  Figure  39.  Note  that  the  help 
pane  indicates  we  are  positioned  at  concepts,  but  we  still  have  two  template  transfor- 
mations enabled,  type  and  value,  which  are  associated  with  phylum  concept.    This 
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feature  minimizes  the  distinction  between  a  singleton  sublist  and  the  list  item  itself,  and 
is  true  for  any  list  phylum.  [Ref.  10:  p.  67] 


Current  butler :  main 

DEFINITION  waiting_passenger 

INHERIT  elevator 

INHERIT  passenger 

<concept> 
END 

Positioned  at  concepts 

type 

value 

Figure  39 
Prompt  for  entering  a  concept 


We  wish  to  add  a  concept  that  returns  a  value,  so  we  invoke  the  execute-command 
command  <  '^l  or  TAB  >  and  enter  v  and  a  carriage  return  to  invoke  the  value 
transformation.  We  are  presented  with  the  template  for  a  concept  that  returns  a  value,  as 
shown  in  Figure  40. 

The  selection  is  positioned  at  formal_name,  the  first  argument  for  phylum  concept. 
After  executing  forward-with-optlonals,  the  selection  is  positioned  at  identifier.  We 
enter  the  name  of  our  concept,  waiting,  and  are  presented  with  the  display  as  shown  in 
Figure  4 1 . 

We  do  not  have  any  formal  parameters,  so  we  invoke  the  transformation  empty. 
However,  we  do  have  a  single  argument  to  concept  waiting.  With  the  selection  at 
formai_arguments,  we  invoke  the  transformation  fieldlist.  This  leaves  the  selection 
positioned  at  field_list  with  transformation  choices  single  and  multiple.  We  invoke 
transformation  single  and  are  presented  with  the  display  as  shown  in  Figure  42. 
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Current  buffer :  main 


DEFINITION  waiting_passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  <formal_args>  <where> 
VALUE  <formal_args> 
<where> 

END 


Positioned  at  formal  name 


Figure  40 
Template  for  a  concept  returning  a  value 


Current  buffer :  main 


DEFINITION  waitingjDassenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting<formal_parm><formal_args>  <where> 
VALUE  <formal_args> 
<where> 


END 


Positioned  at  tormal_parameters  empty        fieldlist 


Figure  41 
Display  after  entering  the  concept  name  waiting 
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Current  buffer :  main 


DEFINITION  waiting  passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting(?)  <where> 
VALUE  <formal_args> 
<where> 

END 


Positioned  at  field  namelist     collection 


Figure  42 
After  invoking  a  single  field_list 


As  we  did  with  actLial_name,  we  will  enter  the  complete  text  required  to  make  up  a 
field,  which  consists  of  a  namejist  and  a  type_spec.  We  type  p  :  passenger 
(including  the  space  either  side  of  the  colon)  and  enter  a  carriage  return.  Note  that  we 
could  have  invoked  the  transformation  namelist,  which  would  have  necessitated  our 
entering  the  namejist  and  type_spec  separately.  As  before,  we  elected  to  enter  the 
complete  construct  at  the  field  node  to  save  time  and  keystrokes. 

The  selection  is  now  positioned  at  the  first  <where>  prompt,  with  two  transfor- 
mations enabled,  empty  and  addwhere.  The  display  appears  as  in  Figure  43. 
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Current  buffer :  main 


DEFINITION  waiting  passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  walting(p  :  passenger)  <where> 
VALUE  <formal_args> 
<where> 

END 


Positioned  at  where  empty        acJdwhere 


Figure  43 
After  entering  the  formal  argument  (p  :  passenger) 


There  is  no  WHERE  clause  that  applies  to  the  formal  arguments,  so  we  invoke 
execute-command,  type  e  and  a  carriage  return  to  invoke  the  empty  transformation. 
We  must  also  execute  forward-with-optionals  to  remove  the  <:where>  prompt  and 
advance  to  the  next  selection. 

The  selection  is  now  positioned  at  the  second  occurrence  of  formal_arguments,  the 
prompt  <formal_args>  after  the  keyword  VALUE.  Two  transformations  are  enabled, 
empty  and  fieldlist.  We  invoke  the  fieldlist  transformation,  which  replaces  the  string 
<formal_args>  with  (<fieid>).  The  help  pane  indicates  the  current  selection  is  fieidjist 
with  two  transformations  enabled,  single  and  multiple.  We  invoke  the  single 
transformation,  and  are  presented  with  a  screen  as  shown  in  Figure  44.  Note  that  the 
completing  term/placeholder  term  for  a  field  (i.e.,  ?  )  has  replaced  the  <field>  prompt 
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Current  bufler :  main 


DEFINITION  warting_passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  warting{p  :  passenger) 
VALUE  (?) 
<where> 

END 


Positioned  at  field  namelist     (X>llection 


Figure  44 
After  invoking  the  single  transformation  for  fieldjist 


Just  as  before,  we  can  enter  the  entire  field  construct  of  a  name_list  and  a 
type_spec  separated  by  a  free-standing  colon.  We  enter  b  :  boolean  and  a  carriage 
return  to  fill  the  field  node  of  the  parse  tree. 

At  this  point,  we  are  called  away  by  our  boss  to  a  meeting  and  we  wish  to  save  our 
work  to  resume  later.  We  execute  the  command  write-named-file  <  ^X^V^  >;  a  pop-up 
window  overlays  the  bottom  of  the  display  screen  for  us  to  enter  iht  filename  and  format 
parameters  to  the  write-named-file  command,  as  shown  in  Figure  45. 

The  selection  is  positioned  at_file_name  in  the  Write  File  Form  window.  We  type 
in  the  desired  name  (including  any  extension);  for  this  example  we  choose  the  name 
waitpass.spec.  Just  as  in  the  object  pane,  we  terminate  text  entry  by  entering  a 
carriage  return.   The  selection  advances  to  _file_type  with  two  transformations  enabled, 
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text  and  structure.  The  default  file  format,  Structure,  is  already  highlighted  in  the  FILE 
FORMAT:  field.  If  you  plan  on  doing  more  editing  on  a  file,  the  recommended  format  in 
which  to  save  the  file  is  Structure.  Text  format  is  used  to  save  the  display  as  a  printable 
file.  Since  the  default  format  is  the  one  we  want,  no  further  entry  is  required.  To 
complete  the  execution  of  the  write-named-file  command  with  our  selected  parameters, 
we  must  execute  start-command  <  ESC-S  >.  This  causes  the  command  line  to  echo 
"Wrote  waitpass.spec",  and  the  actual  file  to  be  written  to  the  file  system. 


Current  buffer :  main 


DEFINITION  wartlng_passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waitlng{p  :  passenger) 
VALUE  (b  :  boolean) 
<where> 

END 


—Current  Form  :  Write  File  Form - ~- 

I 

IWRITE  FILE:  <flle-name>  FILE  FORMAT:  structure 

jPosttioned  at  _file_name 


Figure  45 
Pop-up  Write  File  Form  window 


Note  that  we  arc  still  in  the  editor.  To  exit  the  editor,  we  simply  type  '^C,  which 
deactivates  the  editor  and  returns  us  to  the  Unix  shell. 

To  recall  our  saved  file  back  into  the  editor  for  further  editing,  we  have  two  choices: 
we  can  include  the  filename  waitpass.spec  as  an  argument  to  SPECDEF  when  starting 
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up  the  editor,  or  we  can  start  SPECDEF  with  no  arguments  and  then  execute  the  read-file 
command  <  '^X'^R  or  '^X'^F  >,  which  will  cause  a  pop-up  window  to  appear,  similar  to 
the  Write  File  Form  window  when  we  saved  the  file,  in  which  we  enter  the  filename.  In 
this  example,  we  choose  the  former  method. 

The  initial  display  this  time  includes  the  filename  waitpass.spec  in  the  title  bar,  the 
message  "Read  waitpass.spec"  on  the  command  line,  as  much  of  the  structure  that  will 
fit  in  the  object  pane  (in  this  case  the  entire  file),  and  the  indication  in  the  help  pane  that 
we  are  positioned  at  start.  Figure  46  shows  this  display. 


Current  buffer :  waitpass.spec 


Read  waitpass.spec 


DEFINITION  waiting_passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waitlng(p  :  passenger) 
VALUE  (b  :  boolean) 
<where> 

END 


Positioned  at  start 


Figure  46 
Reading  an  existing  file  into  the  editor 


There  are,  again,  two  choices  on  how  to  proceed:  we  can  either  advance  the  selection 
through  the  entire  parse  tree  using  forward-preorder  <  '^N  >  or  forward-with- 
optionals  <  '^M  or  RETURN  >,  or  we  can  use  end-of-file  <  ESC->  >  to  position  the 

selection  at  the  rightmost  leaf  in  the  parse  tree.  We  choose  the  latter  option  to  save  time. 
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which  now  positions  the  selection  where  we  left  off  during  the  previous  editing  session, 
at  the  second  <where>  prompt  within  the  construct  for  concept. 

We  invoke  the  transformation  addwhere,  which  replaces  the  placeholder  <where> 
with  the  template  for  a  WHERE  clause.  The  selection  is  advanced  to  expression_list 
with  two  transformations  enabled,  single  and  multiple.  We  invoke  the  single  transfor- 
mation, as  shown  in  Figure  47. 


Current  buffer :  waitpass.spec 


COMMAND:  s 


DEFINITION  waiting_passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting(p  :  passenger) 
VALUE  (b  :  boolean) 
WHERE  <expresslon_llst> 

END 


Positioned  at  expressionjist  single         multiple 


Figure  47 
Invoking  the  single  transformation  for  expression_list 


The  selection  is  now  positioned  at  expression.  In  the  SPECDEF  editor,  phylum 
expression  has  more  template  transformations  available  than  can  be  listed  in  the  default 
size  of  the  help  pane  (4  lines).  To  be  able  to  see  all  possible  transformation  names,  the 
help  pane  must  be  enlarged  by  two  lines.  This  is  done  by  executing  the  enlarge-help 
command  <  ESC-'^Xz  >  twice,  once  or  each  line  of  enlargement.  When  this  is  done,  the 
screen  will  appear  as  in  Figure  48.    Notice  that  many  of  the  transformation  names  are 
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symbolic  rather  than  alpha-numeric.     Note  also  the  completing/placeholder  term  for 
expression,  the  symbol  ?,  which  stands  for  an  undefined  expression. 


Current  buffer :  waitpass.spec 

DEFINITION  waiting_passer»ger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting  (p  :  passenger) 
VALUE  (b  :  boolean  ) 
WHERE  ? 

END 

Positioned  at  expression 
1                    implies        iff 

quantity 

< 

actname 

> 

@ 

<» 

& 

~=                ~<              -> 

+ 

in_exp          star            collect 

time              delay          period 

-<= 

/ 

range 

constant 

~>= 

nrxDd 

dot 

lit_type 

*• 

n 

Illegal 

U 

parens 

ifjhen 

uminus 
append 
measure 

Figure  48 
Expanded  Help  Pane  for  expression's  transformations 


The  expression  we  wish  to  enter  is  a  quantified  logic  expression,  so  we  begin  by 
invoking  the  quantify  transformation.  The  placeholder  ?  is  replaced  by  the  template  for 
a  quantified  expression,  as  shown  in  Figure  49. 

We  invoke  the  all  transformation,  which  replaces  the  placeholder  <quantifier>  with 
the  lexeme  ALL  and  advances  the  selection  to  field_list.  In  this  example,  we  want  a 
multiple  field_list,  so  we  invoke  the  multiple  transformation.  The  resulting  display 
appears  as  in  Figure  50. 
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Current  buffer :  waitpass.spec 


DEFINITION  waiting_passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting  (p  :  passenger) 
VALUE  (b  :  boolean  ) 
WHERE  <quantlfier>{<field><restrictlon>  ::  ?) 

END 


Positioned  at  quantifier  all  some  number      sum  product 

set  max  min  union         Intersect 


Figure  49 
After  invoking  the  quantify  transformation  for  expression 


Current  buffer :  waitpass.spec 


DEFINITION  waiting  passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting  (p  :  passenger) 
VALUE  (b  :  boolean  ) 
WHERE  ALL(<field>,?<restriction>  ::  ?) 

END 


Positioned  at  fieldjist  single         multiple 


Figure  50 
After  selecting  multiple  transformation  for  fieldjist 


We  now  address  each  element  of  the  field_list  separately.  For  the  first  element, 
which  is  itself  a  fieldjist,  we  now  invoke  the  single  transformation,  which  replaces  the 
placeholder  <field>  with  the  symbol  ?  and  positions  the  selection  at  field. 
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As  we  have  done  previously,  we  will  enter  the  entire  construct  here  to  save  time  and 
keystrokes;  we  enter  p  :  passenger  followed  by  a  carriage  return.  This  enters  the  text 
and  advances  the  selection  to  the  second  placeholder  for  phylum  field,  the  second  ?. 
Here  we  enter  f  :  floor  and  a  carriage  return.  The  selection  is  now  advanced  to 
restriction,  as  shown  in  Figure  51. 


Current  buffer :  waitpass.spec 


DEFINITION  watting  passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting  (p  :  passenger) 
VALUE  (b  :  boolean  ) 
WHERE  ALL(p  :  passenger ,  f :  floor<restrlction>  ::  ?) 

END 


Positioned  at  restriction  empty         suchthat 


Figure  5 1 
After  entering  a  multiple  fieid_list 


We  do  not  have  any  restrictions  on  these  elements,  so  we  invoke  the  empty  transfor- 
mation. This  places  the  selection  at  expression  following  the  bind  (::)  symbol. 

The  expression  we  wish  to  have  apply  here  is  a  combination  of  several  "and'd" 
expressions  that  imply  a  predicate  expression.  We  start  by  invoking  the  &  transfor- 
mation. This  replaces  the  ?  with  the  string  ?  &  ?.  We  are  still  positioned  at  expression, 
so  we  now  invoke  the  actname  transformation  by  executing  the  execute-command 
command  <  ^1  or  TAB  >  and  then  typing  ac,  which  is  sufficient  to  make  our  choice 
unambiguous.     The  first  placeholder  for  expression  is  replaced  by  the  placeholder 
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<actual_arg>,  and  the  selection  is  advanced  to  actuai_name.  We  enter  the  name  of  the 
predicate  we  wish  to  apply  here,  waiting.  The  selection  is  advanced  to 
actual_argu merits,  with  two  transformations  enabled,  empty  and  arglist.  We  invoke 
the  arglist  transformation  and  are  presented  with  the  display  as  shown  in  Figure  52. 


Current  buffer :  waitpass.spec 


DEFINITION  waiting  passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting  (p  :  passenger) 
VALUE  (b  :  boolean  ) 
WHERE  ALL(p  :  passenger ,  f  :  floor ::  waiting(<arg>)  &  ?) 

END 


Positioned  at  argjist  single         multiple 


Figure  52 
After  invoking  arglist  transformation  for  actual_arguments 


We  enter  the  single  argument  p.  We  then  advance  the  selection  to  expression  using 
forward-with-optionals  <  '^M  or  RETURN  >,  and  invoke  the  &  transformation  once 
more.  Proceeding  similarly  to  the  sequence  described  above,  we  enter  the  various  text 
elements  until  we  have  built  the  expression  at{p  ,  f). 

Advancing  the  selection  again  to  expression,  we  now  invoke  the  implies  transfor- 
mation. With  the  selection  positioned  at  the  ?  on  the  left  side  of  the  =>  symbol,  we  first 
invoke  the  -  transformation  (the  symbol  -  means  "not").  Then  we  proceed  similarly  to 
the  sequence  stated  previously  until  we  have  built  the  expression  ~button_lit(f). 
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Once  more  advancing  the  selection,  we  now  complete  the  expression  on  the  right  side 
of  the  =>  symbol  until  we  have  built  the  expression  pushes_button(p  ,  f).  Our  concept 
waiting  is  now  complete,  as  shown  in  Figure  53. 


Current  buffer :  waitpass.spec 


DEFINITION  waiting  passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  waiting  (p  :  passenger) 
VALUE  (b  :  boolean  ) 
WHERE  ALL{p  :  passenger ,  f :  floor 

::  watting(p)  &  at(p,  f)  &  ~buttonJit(f)  =>  pushes_button(p,  f)) 
<concept> 

END 


Positioned  at  concepts  type  value 


Figure  53 
The  completed  concept  waiting 


Following  a  similar  procedure,  we  add  a  second  concept,  pushes_button.  The 
complete  module  waiting_passenger  now  looks  like  Figure  54. 

We  are  now  ready  to  save  our  module  for  printout.  Wc  invoke  the  write-named-file 
command  <  ^X^VJ  >  as  before.  The  current  filename  waitpass.spec  already  fills  the 
_file_name  field  because  the  filename  is  associated  with  the  current  buffer,  so  we  simply 
enter  a  carriage  return.  This  time  we  want  to  save  the  file  in  text  format  so  we  can  print  it 
out.  We  invoke  execute-command  <  '^i  or  TAB  >  and  type  t  for  the  text  transformation. 
Finally,  we  execute  start-command  <  ESC-s  >  to  actually  write  the  file. 
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Current  buffer :  waltpass.spec 


DEFINITION  waiting_passenger 
INHERIT  elevator 
INHERIT  passenger 

CONCEPT  watting  (p  :  passenger) 
VALUE  (b  :  boolean ) 
WHERE  ALL(p  :  passenger ,  f :  floor 

::  walting(p)  &  at(p.  f)  &  --buttonjlt(f)  «>  pushes_button(p,  f)) 

CONCEPT  pushes_button(p  :  passenger,  f :  floor) 
VALUE  (b  :  boolean) 

END 


Positioned  at  where  empty        addwhere 


Figure  54 
The  complete  module  waiting_passenger 


Since  we  used  the  same  filename  as  the  previously  saved  structure  formatted  file,  the 
contents  of  that  file  are  overwritten  by  the  text  format  of  the  current  buffer.  Now  we  can 
exit  the  editor  by  executing  the  exit  command  <  '^C  >. 

The  file  waitpass.spec  is  now  saved  as  a  standard  ASCII  file  that  appears  the  same 
as  the  display  in  the  object  pane.  The  file  can  be  printed  as  you  would  any  text  file. 

If  the  reader  is  still  unsure  about  any  of  the  commands  that  were  used  in  this  sample 
editing  session,  review  Section  I.E  on  the  commonly  used  commands.  For  a  complete 
list  of  all  commands  available  with  full  descriptions,  see  Chapter  3  of  The  Synthesizer 
Generator  Reference  Manual  [Ref  11 :  pp.  90-  111]. 
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APPENDIX  D 
LIST  OF  EDITOR  COMMANDS 

The  following  is  a  complete  list  of  all  the  available  editor  commands  for  any  editor 
created  by  the  Synthesizer  Generator.  Most  of  the  commands  have  an  associated  key- 
binding.  Those  that  don't  have  a  key-binding  are  indicated  by  (none).  See  Chapter  3  of 

The  Synthesizer  Generator  Reference  Manual  for  a  full  description  of  each  command. 
[Ref.  11] 


advance-afler-transform 

advance-after- parse 

apropos 

ascend-to-parent 

backward-preorder 

backward-sibling 

backward-sibling- with-optionals 

backward-with-optionals 

beginning-of-file 

beginning-of-line 

cancel-command 

column-left 

column-right 

copy-from-clipped 

copy-text-from-clipped 

copy-to-clipped 

cut-to>clipped 

delete-next-cha  racter 

delete-other-windows 

delete-previous-character 

delete-selection 

delete- window 

dump-off 

dump-on 


(none) 
(none) 

<  ESQ-?  > 
<ESC-\> 
<'^P> 

<  ESC-'^P  > 

<  ESC-^B  > 
<'^H> 

<  ESC-<  > 
<'^A> 

<  ESC-c  > 
(none) 
(none) 

<  ESC-'^Y  > 
<^T> 

<  ESC-'^W  > 
<'^W> 
<'^D> 
<^X1  > 
<DEL> 
<'^K> 

(none) 
(none) 
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break-to-debugger 

altemate-unparsing-on 

alternate-unparsing-toggle 

end-of-file 

end-of-line 

enlarge- help 

enlarge- window 

erase-to-beginning-of-line 

erase-to-end-of-line 

execute-command 

execute-monitor-command 

exit 

extend 

extend-start 

extend-stop 

extend-transition 

forward-after-parse 

forward-preorder 

forward-sibling 

forward-sibling-with-optionals 

forward-with-optionals 

help-off 

help-on 

illegal-operation 

insert-file 

left 

list-buffers 

new-buffer 

new-line 

next-line 

next-page 

next-window 

page-left 

page-right 

paste-from-clipped 

pointer-bottom-of-screen 

pointer-down 

pointer-left 

pointer-long-down 

pointer-long-left 

pointer-long-right 

pointer-long-up 

pointer-right 


(none) 
(none) 

<  ESC-e  > 

<  ESC->  > 
<'^E> 

<  ESC-'^Xz  > 

<  ESC-DEL  > 

<  ESC-d  > 
<'^l> 

<'^C> 

<  ESC-(  > 
(none) 
(none) 

<  ESC-X  > 
(none) 

<  ESC-'^N  > 

<  ESC-'^M  > 
<^M> 
(none) 
(none) 
<'^G> 

<  '^X'^l  > 

<  '^X'^B  > 
(none) 
<'^J> 
<^Z> 
<'^V> 
<^Xn> 

<  ESC-{  > 

<  ESC-}  > 
<'^Y> 

<  ESC-.  > 

<  ESC-n  > 

<  ESC-b  > 
(none) 
(none) 
(none) 
(none) 

<  ESC-f  > 
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pointer-top-of-screen 

pointer-up 

previous-line 

previous-page 

previous- window 

read-file 

red  raw-display 

repeat-command 

return-to- monitor 

right 

scroll-to- bottom 

scroll -to-top 

search-forward 

search -reverse 

select 

select-start 

select-stop 

selection -to-left 

selection-to-top 

select-transition 

set-parameters 

show-attribute 

shrink-help 

shrink-window 

spill 

split-current-window 

start-command 

switch-to-buffer 

text-capture 

undo 

alternate-unparsing-off 

visit-file 

write-attribute 

write-current-file 

write-file-exit 

write-modified-files 

write-named-file 

write-selection-to-file 


<  ESC-.  > 

<  ESC-p  > 

<  ESC-z  > 

<  ESC-v  > 
<'^Xp> 

<  '^X'^R  > 

<  ESC-r  > 


<'^F> 
(none) 
(none) 

<  ESC-'^F  > 

<  ESC-'^R  > 

<  ESC-@  > 
(none) 
(none) 
(none) 

<  ESC-!  > 

<  ESC-t  > 
(none) 
(none) 

<  ESC-^X'^Z  > 

<  '^X^Z  > 
(none) 
<'^X2> 

<  ESC-s  > 
<'^Xb> 
(none) 

<  '^X'^U  > 
(none) 

<  '^X'^V  > 
(none) 
(none) 

<  '^X'^F  > 

<  '^X'^M  > 

<  ^X'^W  > 
(none) 
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